MVC
ModelViewController (MVC) هو نموذج تطوير واجهة مستخدم الكمبيوتر يفصل بين منطق عرض المعلومات وتفاعل المستخدم ؛ يحتوي النموذج على بيانات التطبيق ومنطق الأعمال ؛ وحدة التحكم هي المسؤولة عن تحويل إدخال المستخدم إلى أوامر وتمريره إلى النموذج والعرض ؛ هذا هو تفسير ويكيبيديا.
تم تصميم هذا النموذج في الأصل من قبل Trygve Reenskaug عند العمل مع SmallTalk-80 (1979) ، وتم تسميته لأول مرة على محرر موديل العرض. في وقت لاحق ، من خلال المقدمة المتعمقة لكتاب "أنماط التصميم: عناصر البرمجيات الموجهة للكائنات القابلة لإعادة الاستخدام" ، أصبحت MVC شائعة تمامًا ؛
فهم مسؤوليات تكوين الأجزاء الثلاثة من MVC وما توفره لنا أطر عمل JavaScript الحالية حتى نتمكن من استخدام هذه الأطر بشكل أفضل. بعد ذلك ، سنقوم أولاً بتمرير الأجزاء الثلاثة التي تشكل MVC لمعرفة ما هي مسؤوليات كل جزء [بالنظر إلى رمز عرض مع العمود الفقري كمثال].
نموذج
يدير النموذج بيانات التطبيق. عندما تتغير بيانات النموذج ، سيتم إخطار المستمع [ربما وجهة نظر]. بعد تلقي الإشعار ، سيقوم المستمع بإجراء تغييرات مماثلة.
منظر
العرض هو تمثيل مرئي لنموذج الحالة الحالية. سوف يلاحظ العرض تغييرات النموذج ويتم إخطاره عندما يتغير النموذج ، ويسمح للعرض بتحديث نفسه. بشكل عام ، سوف نستخدم محرك القالب لتقديم النموذج في العرض ؛
وحدات التحكم
وحدات التحكم هي وسيط بين النماذج ووجهات النظر. تتمثل مهمتها في تحديث العرض عند تغيير النموذج وتحديث النموذج عندما يقوم المستخدم بتشغيل العرض.
مقارنة إطار عمل Javascipt MVC
الأشخاص المختلفين لديهم طرق مقارنة مختلفة ، يعتمد المفتاح على ما توليه الاهتمام:
1. إذا كنت تولي المزيد من الاهتمام لتفاصيل توجيه عنوان URL الخاص بـ Framework ، وتخزين البيانات ، وتنفيذ العرض ، وما إلى ذلك ، فيمكنك التركيز على هذا ، Throne JavaScript: Sword Sword ؛
2. إذا كنت تولي المزيد من الاهتمام لأمثلة محددة للإطار ، فهناك مشروع مفتوح المصدر هنا يستخدم أطر عمل JavaScript MVC المختلفة لنفس العرض التوضيحي. يمكنك رؤية الاختلافات بوضوح في تطبيقات محددة لكل إطار. هنا هو الموقع الرسمي لـ TODOMVC
فوائد MVC يجلب لنا:
1. من السهل الحفاظ عليها
2. إن فصل طريقة عرض النموذج يعني أنه يمكن اختبار منطق العمل بشكل أفضل.
3. يمكن إعادة استخدام الكود بشكل أفضل
4. يمكن للتطوير المعياري أن يجعل تقسيم العمل أكثر وضوحًا ، ويركز بعض الأشخاص على منطق الأعمال ، ويركز بعض الأشخاص على واجهة المستخدم.
5. بعد مراجعة نموذج MVC الكلاسيكي ، نفهم مفهوم الطبقات في التطبيق ومسؤوليات كل طبقة. في الوقت نفسه ، يجب أن نكون قادرين على تحديد الاختلافات بين جميع أطر JavaScript MVC ونموذج MVC الكلاسيكي الذي نوضحه. وبهذه الطريقة ، عند اختيار إطار عمل MVC ، يجب أن نركز على كيفية تنفيذ النماذج ، ووجهات النظر ، ووحدات التحكم ، وحتى كيفية تنفيذ رموز محددة ، وذلك لمساعدتنا على اختيار إطار عمل JavaScript MVC الأكثر ملاءمة.
MVVM
الاسم الكامل لـ MVVM هو عرض نموذج ViewModel. تم اقتراح هذا النموذج المعماري في الأصل من قبل MartinFowler من Microsoft كمواصفات لنموذج تصميم طبقة عرض Microsoft. إنه مشتق من نموذج MVC. ينصب تركيز نموذج MVVM على منصات تطوير واجهة المستخدم التي يمكن أن تدعم تعتمد على الحدث ، مثل HTML5 ، [2] [3] Foundation Windowspresentation Foundation (WPF) ، Silverlight و T ZK Framework ، Adobe Flex.
يتم فصل معظم تنفيذ هذا النموذج عن الطبقات الأخرى عن طريق إعلان ربط البيانات في طبقة العرض ، مما يسهل تقسيم العمل بين المطورين الأمامي والمطورين الخلفيين. يكتب المطورون في الواجهة الأمامية بيانات ملزمة إلى عرض النموذج في علامة HTML. النموذج و ViewModel هما مطوران خلفيون يحافظون على هاتين الطبقتين من خلال منطق تطوير التطبيقات.
في السنوات الأخيرة ، بدأ تنفيذ نموذج MVVM في JavaScript. حاليًا ، تشمل الأطر الناضجة نسبيًا Knockoutjs و Kendo MVVM و Knockback.js. دعنا نأخذ KnockoutJs كمثال لرؤية المسؤوليات المحددة ورموز مثال لكل جزء من نموذج MVVM ، وفي الوقت نفسه فهم مزايا وعيوب استخدام هذا النموذج لتطويرها.
نموذج
مثل أفراد عائلة MV* الآخرين ، يمثل النموذج البيانات في حقل أو بيانات محددة مطلوبة للتطبيق ، أو بيانات نموذجية خاصة بالحقل مثل معلومات المستخدم [اسم المستخدم أو الصورة الرمزية أو البريد الإلكتروني أو رقم الهاتف] أو معلومات موسيقية [اسم الأغنية ، سنة الإصدار ، الألبوم] ؛
يركز النموذج فقط على معلومات البيانات ولا يهتم بأي سلوك ؛ لا ينظم البيانات أو يؤثر على عرض البيانات في المتصفح ، وهو ليس مسؤوليته ؛ إن تنسيق البيانات هو مهمة طبقة العرض ، ويتم تغليف طبقة منطق العمل في نموذج العرض للتفاعل مع النموذج.
السلوك غير المتوقع الذي تم إجراؤه في طبقة النموذج هو التحقق من البيانات. على سبيل المثال ، عندما يدخل المستخدم البريد الإلكتروني ، حدد ما إذا كان تنسيق البريد الإلكتروني صحيحًا.
في KnockOutJs ، يتم تنفيذ النموذج بشكل أساسي وفقًا للتعريف أعلاه ، ولكن سيكون هناك خدمة خادم الاتصال Ajax لقراءة وكتابة بيانات النموذج.
منظر
يشير العرض إلى جزء التطبيق الذي يتفاعل مباشرة مع المستخدم. إنه واجهة مستخدم تفاعلية لتمثيل حالة ViewModel. يعتبر العرض نشطًا وليس سلبيًا؟ هذه الجملة تعني أن العرض السلبي لا يهتم بمجال النموذج في التطبيق ، ويتم الحفاظ على مجال النموذج في وحدة التحكم ؛ تتضمن العرض النشط لـ MVVM ربط البيانات والأحداث وسلوك النموذج و ViewModel. على الرغم من أن هذه السلوكيات يمكن أن تتوافق مع السمات ، إلا أن العرض لا يزال يحتاج إلى الاستجابة لحدث ViewModel ، ولا يكون العرض مسؤولاً عن السيطرة على الحالة.
طبقة العرض الخاصة بـ KnockoutJS هي مستند HTML بسيط ، والذي سيرتبط بإعلان البيانات الخاص بـ ViewModel. في الوقت نفسه ، تعرض طبقة العرض من KnockOutJs البيانات التي تم الحصول عليها من ViewModel ، وتنقل الأوامر إلى ViewModel ، وتحديث الحالة التي تم تغييرها في ViewModel.
ViewModel
يمكن اعتبار أن ViewModel عبارة عن وحدة تحكم تستخدم خصيصًا لتحويل البيانات. يمكنه تحويل المعلومات الموجودة في النموذج إلى معلومات في العرض ، وفي نفس الوقت تمرير أوامر من العرض إلى النموذج ؛
وبهذا المعنى ، يبدو ViewModel أشبه بنموذج ، لكنه يتحكم في الكثير من منطق العرض للعرض. في الوقت نفسه ، تكشف ViewModel أيضًا بعض الطرق للحفاظ على حالة العرض وتحديث النموذج وفقًا لسلوك العرض والأحداث ؛
باختصار ، يقع ViewModel خلف طبقة واجهة المستخدم ، ويمكن اعتبار تعريض البيانات إلى العرض مصدر بيانات وسلوك طبقة العرض ؛
يفسر KnockOutJS ViewModels على أنه عرض للبيانات والسلوكيات المعبر عنها على واجهة المستخدم. إنه ليس نموذج بيانات يحتاج إلى استمرار ، ولكن يمكنه الاحتفاظ بالبيانات المخزنة من قبل المستخدم. يتم تنفيذ ViewModels من Knockout باستخدام كائنات JavaScript ، وليس هناك حاجة لرعاية علامات HTML. هذه الطريقة التجريدية يمكن أن تبقي تنفيذها بسيطة.
ميزة:
1. MVVM يجعل التنمية المتوازية أسهل ، بحيث لا يؤثر المطورون في الواجهة الأمامية والمطورين الخلفيين على بعضهم البعض.
2. ملخص طبقة العرض ، مما يقلل من منطق العمل في الكود
3. ViewModel أسهل في الاختبار من الحدث الذي يحركه الأحداث
4. لا يحتاج اختبار ViewModel إلى الاهتمام بأتمتة واجهة المستخدم وتفاعلها
عيب:
1. بالنسبة للوديل البسيط ، فإن استخدام MVVM ثقيل بعض الشيء
2. إن ربط البيانات التصريحي لا يفضي إلى تصحيح الأخطاء ، لأن الكود الضروري يمكن أن يضبط بسهولة نقاط التوقف ، وهذا الوضع لا يفضي إلى وضع نقاط التوقف هذه.
3. يمكن أن يؤدي ربط البيانات إلى إنشاء الكثير من الحفاظ على الدفاتر في التطبيقات غير التافهة. أنت أيضًا لا تريد أن ينتهي الأمر بموقف أكثر تعقيدًا يكون فيه الربط أكثر تعقيدًا من الكائن المرتبط.
4. في التطبيقات الكبيرة ، من الصعب تصميم طبقة طراز العرض قبل الحصول على عدد كبير من التعميمات.