الصفحة الرئيسية>كود مصدر ASP>فئات أخرى
تنزيل

غرف الدردشة التجريبية

go+iris+jwt+mysql+xorm+viper، وهي غرفة دردشة بسيطة لمشروع iris، بما في ذلك تسجيل الدخول والتسجيل والدردشة الخاصة والدردشة الجماعية.

تصفح التجريبي

أولاً، قم بإلقاء نظرة على مقدمة الواجهة الأمامية الموجودة أسفل هذا المستند لمعرفة كيفية تشغيلها (بسبب الطاقة المحدودة، فإن واجهة المستخدم ليست سهلة الاستخدام بشكل خاص).

الوصول إلى العنوان التجريبي إذا كانت حالة الرمز الصغير أعلاه طبيعية، فيمكنك الوصول إليه في حالة خاملة وتحتاج إلى الانتظار لبضع ثوان.

بداية المشروع

يقوم المشروع حاليًا بكتابة التعديلات المتعلقة بـ mysql فقط، ولكن باستخدام xorm، ليس من الصعب دعم قواعد البيانات الأخرى، لكن هذا ليس ضروريًا. إذا كنت كسولًا جدًا لتشغيله بنفسك، فما عليك سوى إلقاء نظرة على عنوان URL التجريبي إذا كنت مهتمًا، فلا أحد لديه MySQL الآن.

كنت أرغب في الأصل في دعم sqlite، لذلك ليست هناك حاجة لتكوين معلمات قاعدة البيانات، ولكن بالنظر إلى أن تجميع sqlite تحت Windows يتطلب تكوين بيئة دول مجلس التعاون الخليجي، وهو أمر أكثر إزعاجًا، ولكن لا يوجد تأثير بدء تشغيل سريع، وهو ببساطة غير مكتمل ، لذا فإن قواعد البيانات الأخرى غير مدعومة في الوقت الحالي (أضف المزيد يومًا ما عندما يكون لديك الوقت).

لذلك يحتاج المشروع فقط إلى تكوين المعلمات التالية

  • تكوين بيئة التشغيل go (يمكن استخدام الإصدار 1.8 الذي تم اختباره بالفعل، ولكن يوصى باتباع الإصدار الأحدث، وحدة go الجديدة سهلة الاستخدام للغاية)
  • منفذ بدء تشغيل المشروع (الافتراضي 8888)
  • عنوان قاعدة البيانات
  • اسم المستخدم
  • كلمة المرور
  • اسم قاعدة البيانات (وبناء قاعدة البيانات مقدما، ليست هناك حاجة إلى الجداول) 
git clone https://github.com/JabinGP/demo-chatroom.git
cd demo-chatroom
// 复制config.toml.example 为 config.toml 并填写数据库信息，或者可选修改端口号
go run main.go

الافتراضي هو المنفذ 8888. بعد بدء التشغيل، قم بالوصول إلى http://localhost:8888

الواجهة الأمامية

لقد استخدمت رد الفعل، لكن لم أستخدم إطار عمل واجهة المستخدم، ولم يتم تنفيذ العديد من التفاصيل الصغيرة بشكل جيد. دعونا نكتفي بهذا.

يقوم مربع الدردشة بضبط النافذة للتمرير تلقائيًا إلى الأسفل، ولكن يتم توفير واجهة برمجة التطبيقات بواسطة React وتبين أنها غير متوافقة مع العديد من المتصفحات. يمكن حل هذه المشكلة باستخدام متصفح Chrome.

بعد التسجيل، ارجع يدويًا واختر تسجيل الدخول. الاسم الأحمر في مربع الرسالة مخصص للكلام العام، والاسم الرمادي مخصص للدردشة الخاصة. يمكنك تحديد اسم المستلم في المربع الأحمر إذا لم يتم تحديده، فالاسم الافتراضي هو بعد التحديد، يمكن للمستخدمين المعنيين فقط رؤية المعلومات.

يتم عرض اسم المستخدم الخاص بك في المربع الأزرق. انقر لتسجيل الخروج مباشرة.

نهاية الطريق

يعتمد تنسيق واجهة برمجة التطبيقات على تصميم مريح، ويتم إكمال وظيفة تسجيل الدخول باستخدام jwt. تتطلب العديد من الواجهات حالة تسجيل الدخول، ويجب حمل JWT عند الطلب تم ضبط وقت صلاحية إصدار JWT على 20 دقيقة فقط ويجب أن تنتهي صلاحيته.

تنسيق طلب واجهة برمجة التطبيقات هو نفس الواجهة العامة. يستخدم Get Params، ويستخدم Post وPut وDelete وما إلى ذلك Json in Body لتمرير المعلمات.

تنسيق الإرجاع مثير للجدل تمامًا، لقد كنت أدرسه منذ فترة، ويؤيد بعض الأشخاص استخدام رمز الحالة 200 http الكامل وإضافة رمز إلى محتوى الإرجاع لتحديد الخطأ، مثل هذا: 

 // 注册错误时
// http status 200
{
  "code" : 40001 ,
  "msg" : "注册用户名非法"
}
 // 注册成功时
// http status 200
{
  "code" : 200 ,
  "msg" : "成功" ,
  "data" : {
    "username" : " JabinGP " ,
    "id" : 3
  }
}

ويدافع آخرون عن استخدام رموز حالة http الكاملة للإشارة إلى الأخطاء: 

 // 注册错误时
// http status 400
{
  "msg" : "注册用户名非法"
}
 // 注册成功时
// http status 200
{
  "username" : " JabinGP " ,
  "id" : 3
}

في الواقع، كلا النهجين المذكورين أعلاه لهما إيجابيات وسلبيات:

  • الأول هو تسهيل معالجة الأخطاء وتنسيقات الإرجاع للمبرمجين الخلفيين. ليست هناك حاجة للتحكم يدويًا في رمز الحالة لاستجابة http. لكنهم يحتاجون فقط إلى التحكم في الإرجاع كل ذلك للإشارة إلى حالة الطلب، وهي غير متسقة. كما أن المواصفات المريحة لا تساعد على مراقبة الطلب والإحصائيات على Linux، كما أنها ستتسبب في أن يكون لدى مبرمجي الواجهة الأمامية أساليب كتابة قبيحة مثل res.data.data عند كتابة ajax ، وفي اياكس لا يمكن ضمان النجاح في رد الاتصال الناجح، ويجب استدعاء Res.data.code مرة أخرى في رد الاتصال الناجح لتحديد ما إذا كان الطلب طبيعيًا، ومع ذلك، يمكن لتبديل الأخطاء التعامل مع أخطاء 404 فقط.
  • النوع الثاني غير مناسب للمبرمجين الخلفيين، فهم يحتاجون إلى التحكم بشكل إضافي في استجابة http، ورمز حالة http محدود للغاية ولا يمكنه التعبير عن حالة الخطأ للطلب بشكل جيد. بالنسبة للأخطاء المختلفة، من المستحيل العثور على الصحيح رمز حالة http للاستجابة. الميزة هي أن مبرمجي الواجهة الأمامية لا يحتاجون إلى كتابة res.data.data وحكم إضافي res.data.code. يمثل رد الاتصال الناجح النجاح، ويمثل رد الاتصال الخطأ خطأً، لكن مبرمج الواجهة الأمامية يفقد الدقة الرقم (مثل 40001 في المثال)) للتعامل مع الخطأ المقابل، لا يمكنك الحكم عليه إلا من خلال رمز حالة http على الأكثر، سيتم عرض المعلومات الموجودة في الرسالة للمستخدم، ولا يمكن إجراء المزيد من المعالجة.

بناءً على الوضع أعلاه، سأجمع بين الأمرين:

عند النجاح، قم بإرجاع رمز حالة http 200 

 // 注册成功时
// http status 200
{
  "username" : " JabinGP " ,
  "id" : 3
}

عند حدوث فشل، حدد عدة رموز حالة شائعة الاستخدام للتعبير عن الخطأ، 400 (خطأ في الطلب)، 500 (خطأ داخلي في الخادم)، 404 (غير موجود)، 401 (فشل المصادقة)، وصنف الخطأ تقريبًا، ثم قم بإرجاع تخصيص ملف الرمز والرسالة والتفاصيل في البيانات لتمثيل سبب الخطأ التفصيلي: 

 // 注册失败
// http status 400
{
  "code" : 6 ,
  "msg" : "数据检验失败" ,
  "detail" : "用户名已存在"
}
 // 登录失效
// http status 401
{
  "code" : 8 ,
  "msg" : "未认证登录" ,
  "detail" : " Token is expired "
}

بعد هذا الجمع، يكون رد الاتصال الناجح ناجحًا، وليست هناك حاجة لكتابة res.data.data بشكل متكرر، يعالج رد الاتصال الخطأ الأخطاء فقط، والتي يمكن الحكم عليها من خلال رمز حالة http، ويمكن أيضًا تشفيرها ورسائلها وحذفها. مفصلة لمعالجة الأخطاء.

قائمة واجهة برمجة التطبيقات هي كما يلي. استبدل المضيف المحلي بـ mike.jabingp.cn أو يمكنك طلب الواجهة الخلفية التجريبية مباشرةً:

وظيفة طريقة الطلب عنوان
الحصول على رمز تسجيل الدخول بريد http://localhost:8888/v1/login
ابحث عن المستخدمين يحصل http://localhost:8888/v1/user
يسجل بريد http://localhost:8888/v1/user
يقوم المستخدمون بتعديل المعلومات بأنفسهم يضع http://localhost:8888/v1/user
يرسل المستخدم رسالة بريد http://localhost:8888/v1/message
يحصل المستخدم على المعلومات يحصل http://localhost:8888/v1/message
يحصل المستخدم على معلومات الرمز المميز يحصل http://localhost:8888/v1/token/info

يمكن الاطلاع على معلمات الطلب التفصيلية في وثائق Postman-api الخاصة بغرفة الدردشة التجريبية.

أو عرض الكود المصدري يمكن عرض معلمات الطلب في model/reqo ويمكن عرض معلمات الاستجابة في model/reso

مقدمة

AJAX ليس الخيار الأفضل لوظيفة الدردشة، لكن WebSocket هو الأفضل، لكن طُلب مني استخدام AJAX لذلك لم أختر الأخير.

الواجهة الأمامية للمشروع بسيطة نسبيًا لأنها تستخدم فقط كعرض توضيحي.

لغتي الإنجليزية ليست جيدة جدًا، وتعليقات الكود باللغة الإنجليزية فقط لأنني كسول جدًا بحيث لا يمكنني تبديل طريقة الإدخال.

هذه هي المرة الأولى التي أستخدم فيها go لتطوير مشروع ويب، وهي أيضًا المرة الأولى التي أستخدم فيها رد الفعل لكتابة الواجهة الأمامية، نظرًا لأن الواجهة الأمامية لا تهتم كثيرًا ببنية المشروع (xjbx)، فلن أفعل ذلك ضع الكود المصدري، وأقوم بتجميع المشروع ووضعه في مجلد الأصول لسهولة القراءة، ولكن يمكن البدء به مع الواجهة الخلفية، وليست هناك حاجة لبدء الواجهة الأمامية بشكل منفصل، وهو أمر أكثر ملاءمة لرؤية ذلك تأثير. إذا كان لا يزال لدي الوقت، فسأفكر في كتابة نسخة مبسطة باللغة الأصلية لتكون مرجعًا للجميع.

في المرة الأولى التي استخدمت فيها ORM لتشغيل قاعدة بيانات، وجدت أنه من الصعب جدًا استخدامها. كنت أفضل كتابة SQL يدويًا. كان هناك العديد من التأثيرات المرغوبة ولم أتمكن من العثور على حل بعد البحث في المستندات لفترة طويلة قد أفكر في استخدام sqlx لإعادة الإعمار لاحقًا.

مصدر المشروع

في الآونة الأخيرة، أصبحت أكثر اهتمامًا بـ Go، وتلقيت مهمة لكتابة غرفة دردشة بسيطة، ووجدت أن هناك حاليًا عددًا قليلاً من ممارسات المشروع في القزحية، فقط بعض الأمثلة على مستوى HelloWorld، لذلك قررت استخدام Go للقيام بذلك. ، ومن ثم فتحه كمرجع مشترك. بالطبع، تعتمد كيفية تصميم هيكل المشروع بالكامل على خبرتي المحدودة في التطوير. يرجى تقديم آرائكم القيمة بشأن أي جوانب غير معقولة.

أبرز معالم المشروع

هذا المشروع لديه المتطلبات التالية

  1. على أساس أجاكس
  2. تحتاج الصفحة الأمامية إلى التحديث (تحديث البيانات تلقائيًا)
  3. وظيفة تسجيل الدخول
  4. وظيفة التسجيل (تتطلب اسم المستخدم وكلمة المرور والجنس والعمر والاهتمامات والهوايات)

أفكار التنفيذ

وظيفة تسجيل الدخول

يتم تنفيذ وظيفة تسجيل الدخول باستخدام JWT هذه المرة، ولن تتم مناقشة مزايا وعيوب JWT و Session بالتفصيل.

يعتمد على AJAX ولا يوجد تحديث

يعد الاعتماد على AJAX أمرًا ضروريًا لجميع مشاريع الفصل بين الواجهة الأمامية والخلفية، لذلك لن تتم مناقشة هذه الوظيفة كثيرًا. ما هي الصعوبة في التركيز هنا؟

متطلبات تشغيل المستخدم

منطق تشغيل المستخدم هو إرسال البيانات إلى غرفة الدردشة، ثم يتم إرسال البيانات. يجب أن تعرض واجهة الدردشة البيانات المرسلة بنفسها وتحديث البيانات المرسلة من قبل الآخرين في الوقت الفعلي.

منطق العملية الأمامية

تتواصل الواجهة الأمامية والخلفية من خلال AJAX ويمكن التعبير عن بيانات الإرسال الأمامية وبيانات الإرسال الخلفية

  • إرسال البيانات: تحمل الواجهة الأمامية البيانات التي سيتم إرسالها في الطلب بتنسيق JSON
  • الحصول على البيانات: تطلب الواجهة الأمامية من الخلفية الحصول على واجهة الرسائل للحصول على آخر الأخبار.

ما هي المشكلة هنا؟ المشكلة هي أن الواجهة الأمامية يمكنها فقط بدء الطلبات بشكل نشط، والواجهة الخلفية يمكنها قبول الطلبات فقط. وهذا يعني أنه لا يمكن أبدًا إرسال أحدث الرسائل بشكل نشط من الواجهة الخلفية إلى الواجهة الأمامية في الوقت الفعلي. لا يمكن تخزين أحدث الرسائل إلا في الواجهة الخلفية أولاً، ثم انتظر حتى تبدأ الواجهة الأمامية طلبًا قبل أن تتمكن الواجهة الخلفية من إرجاع البيانات.

نظرًا لأن الواجهة الخلفية لا تملك القدرة على دفع الرسائل بشكل نشط إلى الواجهة الأمامية، فإن الحل بالنسبة للمستخدمين للحصول على أحدث البيانات هو أن تقوم الواجهة الأمامية بتعيين مؤقت每隔一段比较短的时间就请求一次后台接口（轮询） ، بحيث يمكن تحديث البيانات بشكل مستمر.

منطق العمليات الخلفية

قررت الواجهة الأمامية استخدام AJAX لاستقصاء واجهة الخلفية بانتظام للحصول على أحدث البيانات، ومن أجل الحصول على البيانات في الوقت الفعلي، سيكون الفاصل الزمني للاستقصاء小于1s سيؤدي هذا إلى مشكلة أخرى، في ظل هذه الطلبات المتكررة، يجب ألا تقوم الواجهة الخلفية بنقل جميع البيانات في كل مرة. أحدهما هو حجم البيانات الناتج عن كفاءة نقل الشبكة وتكلفة المرور إن حكم الواجهة الأمامية على البيانات الجديدة يعني أن الواجهة الخلفية يجب أن تُرجع البيانات التي لم تتلقاها الواجهة الأمامية في كل مرة. المشكلة هي - كيف تعرف الواجهة الخلفية المعلومات التي تلقتها الواجهة الأمامية؟

يتطلب هذا استخدام自增主键للرسالة، وتحتاج الواجهة الأمامية فقط إلى حمل最后的消息的主键تتلقاها الواجهة الأمامية في كل مرة تقوم فيها بتقديم طلب. من خلال التكرار والزيادة التلقائية، يمكننا بسهولة معرفة النسبة، والبيانات التي تحتوي على مفتاح أساسي كبير هي البيانات التي لم تتلقاها الواجهة الأمامية بعد.

كومة تكنولوجيا المشروع

  • لغة

    • جولانج
    • HTML
    • CSS
    • جافا سكريبت

  • إطار

    • إطار عمل الواجهة الخلفية للقزحية
    • رد فعل الإطار الأمامي
    • إطار ORM لقاعدة بيانات Xorm
    • دعم قراءة ملف التكوين متعدد الأنواع من Viper

  • تخزين البيانات

    • قاعدة بيانات Mysql الكلاسيكية

  • تكنولوجيا

    • يصدر JWT رمز تسجيل الدخول
    • AJAX طلب غير متزامن للبيانات الخلفية

هيكل تصميم قاعدة البيانات

نظرًا لاستخدام إطار عمل ORM لقاعدة بيانات Xorm، يتم إنشاء الجداول التالية تلقائيًا وتأتي مع الحقل xxxxxx_at

وبناء على المتطلبات المذكورة أعلاه، تم تصميم جدولين، users messages .

المستخدمين

الحقول الرئيسية

  • بطاقة تعريف
  • اسم المستخدم
  • passwd
  • جنس
  • عمر
  • اهتمام

هيكل جدول قاعدة البيانات

مجال يكتب باطل مفتاح تقصير إضافي
بطاقة تعريف كبير(20) لا بري باطل زيادة تلقائية
اسم المستخدم فارتشار(255) نعم باطل
passwd فارتشار(255) نعم باطل
جنس كبير(20) نعم باطل
عمر كبير(20) نعم باطل
اهتمام فارتشار(255) نعم باطل
create_at التاريخ والوقت نعم باطل
update_at التاريخ والوقت نعم باطل
deleted_at التاريخ والوقت نعم باطل

رسائل

الحقول الرئيسية

  • بطاقة تعريف
  • sender_id -> مرسل الرسالة المقابل
  • المتلقي_معرف -> مستقبل الرسالة المقابلة
  • محتوى
  • send_time

هيكل جدول قاعدة البيانات

مجال يكتب باطل مفتاح تقصير إضافي
بطاقة تعريف كبير(20) لا بري باطل زيادة تلقائية
sender_id كبير(20) نعم باطل
معرف الاستقبال كبير(20) نعم باطل
محتوى فارتشار(255) نعم باطل
send_time كبير(20) نعم باطل
create_at التاريخ والوقت نعم باطل
update_at التاريخ والوقت نعم باطل
deleted_at التاريخ والوقت نعم باطل

هيكل المشروع

يعتمد الهيكل التالي على الخبرة الشخصية. إذا كان هناك أي شيء غير مناسب، فيرجى تزويدنا بتعليقاتك القيمة.

  • طبقة توجيه المسار، المسؤولة عن تعيين طلبات "xxxxxx" إلى الوظائف المقابلة
  • البرمجيات الوسيطة يمكن لطبقة البرمجيات الوسيطة أن تعترض وتعالج قبل وبعد تنفيذ الوظائف، مثل اعتراض تسجيل الدخول.
  • تقوم طبقة التحكم في وحدة التحكم بتخزين الوظائف المقابلة لطلب "xxxxxx" وفقًا للطلب، ويتم استدعاء طبقة الأعمال وتنسيق البيانات وإرجاعها.
  • طبقة أعمال الخدمة، واستدعاء طبقة الثبات لإكمال منطق العمل
  • يمكن فهم طبقة استمرار داو على أنها تغليف من تنفيذ SQL إلى تنفيذ الوظيفة. نظرًا لاستخدام ORM، لا يحتوي هذا المشروع على دليل طبقة داو.
  • توفر قاعدة البيانات اتصال قاعدة البيانات
  • يحدد النموذج سلسلة من الهياكل
    • كيانات منطق الأعمال pojo، مثل المستخدم والرسالة
    • يطلب reqo كيانات بيانات تتوافق مع كل طريقة في وحدة التحكم
    • يستجيب reso لكيانات البيانات المقابلة لكل طريقة في وحدة التحكم
  • يقرأ config التكوين ويوفر مثيلًا واحدًا لكيان ملف التكوين للوصول الخارجي.
  • طبقة أداة الأداة
  • دليل الموارد الثابتة للأصول، الذي يخزن الموارد الثابتة (ملفات الواجهة الأمامية)

ما هي pojo، reqo و reso؟

  • بوجو

    من السهل أن نفهم أنه الكيان المطابق لقاعدة البيانات، لكنه لا يتطلب مراسلات فردية مع حقول قاعدة البيانات.

  • reqo (كائن الطلب)، reso (كائن الاستجابة)

    عند تقديم الطلبات من خلال واجهات مختلفة، تختلف أيضًا المعلمات التي يمكن حملها وبيانات الاستجابة، لذلك تم تصميم كيان الطلب وكيان الاستجابة المقابل لكل واجهة.

ما الفرق بين وحدة التحكم والخدمة والداو؟

وفيما يلي فهمي الشخصي

  • المراقب المالي

    المسؤولية الرئيسية هي قبول معلمات الطلب الخاصة بالطلب، وتحويلها إلى reqo، وإجراء التحقق البسيط من معلمات الطلب (تعريفي الشخصي هو التحقق الذي لا علاقة له بقاعدة البيانات، مثل غير فارغ، وغير صفري)، والاتصال وظيفة طبقة الخدمة هي الحصول على نتيجة pojo، ويتم تغليف تحويل نتيجة pojo وإعادته في reso.

  • خدمة

    تتمثل المسؤولية الرئيسية في تغليف واجهة طبقة Dao بشكل أكبر وتوفير واجهة مشتركة لوحدة التحكم للاتصال بها. يمكن إجراء التحقق من البيانات في الخدمة، مثل (إضافة مستخدمين جدد، والتحقق مما إذا كان اسم المستخدم مكرر).

  • داو

    في الأساس، تتوافق الطريقة هنا مباشرة مع عبارة SQL دون أي تحقق، وتعتبر البيانات المستلمة موثوقة (تم التحقق منها بواسطة معلمات طبقة وحدة التحكم والخدمة)، ويمكن أن تكون البيانات التي تم إرجاعها POJO.

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل