الأساليب "المعمارية" البديلة لرمز عميل جافا سكريبت؟

Question

كيف يتم تنظيم كود جافا سكريبت الخاص بك؟هل يتبع أنماطًا مثل MVC أو أي شيء آخر؟

لقد كنت أعمل في مشروع جانبي منذ بعض الوقت، وكلما تقدمت في الأمر، تحولت صفحة الويب الخاصة بي إلى تطبيق كامل المواصفات.في الوقت الحالي، أنا متمسك بـ مسج, ومع ذلك، فإن المنطق الموجود على الصفحة يتزايد إلى حد أن هناك حاجة إلى بعض التنظيم، أو أجرؤ على قول ذلك، "الهندسة المعمارية".نهجي الأول هو "MVC-ish":

• "النموذج" عبارة عن شجرة JSON يتم تمديدها باستخدام المساعدين
• العرض هو فئات DOM plus التي تقوم بتعديله
• وحدة التحكم هي الكائن الذي أقوم بتوصيل معالجة الأحداث فيه وبدء العرض أو معالجة النموذج

ومع ذلك، فأنا مهتم جدًا بكيفية قيام الآخرين ببناء تطبيقات جافا سكريبت أكثر أهمية.لست مهتمًا بـ GWT أو الأساليب الأخرى الموجهة نحو الخادم ...فقط في نهج "javaScript + <generic webservice-y thingy here>"

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

Answer 1

.. لكن جافا سكريبت لها جوانب عديدة نكون س.

النظر في هذا:

var Vehicle = jQuery.Class.create({ 
   init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
   fillGas: function(){ 
      this.gas = 100; 
   } 
});

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

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

Answer 2

يعد JavaScriptMVC خيارًا رائعًا لتنظيم وتطوير تطبيق JS واسع النطاق.

التصميم المعماري مدروس جيدًا.هناك 4 أشياء يمكنك القيام بها باستخدام JavaScript:

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

تقوم JMVC بتقسيمها إلى نمط النموذج والعرض ووحدة التحكم.

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

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

التالي يأتي النموذج.يوفر JMVC فئة أساسية ونموذجًا قويًا يتيح لك تنظيم وظائف Ajax بسرعة (#2) وتغليف البيانات بوظيفة محددة للمجال (#3).عند الانتهاء، يمكنك استخدام النماذج من وحدة التحكم الخاصة بك مثل:

تودو.العثور على الكل({بعد:new Date()}, myCallbackFunction);

أخيرًا، بمجرد عودة المهام الخاصة بك، يجب عليك عرضها (#4).هذا هو المكان الذي تستخدم فيه عرض JMVC.

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

في "طرق العرض/جميع المهام/list.ejs"

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

توفر JMVC أكثر بكثير من مجرد الهندسة المعمارية.يساعدك في أي جزء من دورة التطوير من خلال:

• مولدات الكود
• اختبار متكامل للمتصفح والسيلينيوم ووحيد القرن
• توثيق
• ضغط البرنامج النصي
• الإبلاغ عن الأخطاء

Answer 3

MochiKit رائع - وكان حبي الأول، إذا جاز التعبير، فيما يتعلق بمكتبات js.لكنني وجدت أنه على الرغم من أن MochiKit يحتوي على بناء جملة معبر للغاية، إلا أنه لم يكن مريحًا بالنسبة لي كما كان يفعل Prototype/Scriptaculous أو jQuery بالنسبة لي.

أعتقد أنه إذا كنت تعرف لغة بايثون أو تحبها، فإن MochiKit هي أداة جيدة لك.

Answer 4

شكرا لكم جميعا على إجاباتكم.وبعد مرور بعض الوقت، أود أن أنشر ما تعلمته حتى الآن.

حتى الآن، أرى فرقًا كبيرًا جدًا في النهج الذي يستخدم شيئًا مثل تحويلة, ، وغيرهم مثل واجهة مستخدم مسج, مكتوب, MochiKit, ، إلخ.

مع Ext، يكون HTML مجرد عنصر نائب واحد - تظهر واجهة المستخدم هنا.ومنذ ذلك الحين، كل شئ موصوف في جافا سكريبت.يتم تقليل تفاعل DOM ضمن طبقة API أخرى (ربما أقوى).

مع المجموعات الأخرى، أجد نفسي أبدأ بالقيام ببعض تصميم HTML، ثم توسيع DOM مباشرة بتأثيرات رائعة، أو مجرد استبدال إدخال النموذج هنا، وإضافة هناك.

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

ألاحظ أن العديد من هذه المكتبات تتضمن أيضًا بعض تقنيات الوحدات المثيرة للاهتمام أيضًا.تمت المساهمة بوصف واضح جدًا على موقع Ext الإلكتروني، والذي يتضمن طريقة رائعة "لحماية" التعليمات البرمجية الخاصة بك باستخدام الوحدات النمطية.

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

Answer 5

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

لقد رأيت محاولة واحدة منذ فترة حيث قام شخص ما بإنشاء إطار عمل لنمذجة البيانات في JavaScript، تمامًا مثل الطريقة التي ينتمي بها SQLite إلى التطبيق.كان مثل Model.select( "Product" ) و Model.update( "Product"، "Some data...").لقد كان في الأساس عبارة عن تدوين كائن يحتوي على مجموعة من البيانات لإدارة حالة الصفحة الحالية.ومع ذلك، في اللحظة التي تقوم فيها بالتحديث، يتم فقدان كل تلك البيانات.ربما أكون خارج نطاق بناء الجملة، لكنك تفهم هذه النقطة.

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

Answer 6

مجرد توضيح سريع.

من الممكن تمامًا كتابة تطبيقات GWT غير الموجهة نحو الخادم.أفترض أنه من موجه نحو الخادم تقصد GWT RPC الذي يحتاج إلى واجهة خلفية تعتمد على جافا.

لقد كتبت تطبيقات GWT تعتبر "MVC-ish" من جانب العميل وحده.

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

إذا كانت خلفيتك "المكتوبة بقوة" تستخدم لغة Java أو لغة مشابهة، فأعتقد أنك يجب أن تفكر بجدية في استخدام GWT للمشاريع الكبيرة.بالنسبة للمشاريع الصغيرة، عادةً ما أفضّل jQuery.القادمة GWTQuery الذي يعمل مع GWT 1.5 قد يغير ذلك ولكن ليس في المستقبل القريب بسبب وفرة المكونات الإضافية لـ jQuery.

Answer 7

لست متأكدًا بنسبة 100% مما تقصده هنا، ولكنني سأقول أنه بعد استخدام ASP.NET على مدار الأعوام الستة الماضية، أصبحت صفحات الويب الخاصة بي الآن مدفوعة في الغالب بواسطة JavaScript بمجرد انتهاء الخادم من عرض الصفحة الأساسي.أستخدم JSON في كل شيء (منذ حوالي 3 سنوات) وأستخدمه MochiKit لاحتياجاتي من جانب العميل.

بالمناسبة، جافا سكريبت يكون OO، ولكن نظرًا لأنه يستخدم الميراث النموذجي، فإن الناس لا يمنحونه الفضل بهذه الطريقة.أود أيضًا أن أزعم أنها عملية أيضًا، كل هذا يتوقف على كيفية كتابتها.إذا كنت مهتمًا حقًا بأساليب البرمجة الوظيفية، فاطلع على ذلك MochiKit - قد تعجبك؛إنه يميل قليلاً نحو جانب البرمجة الوظيفية لجافا سكريبت.