العمارة الواجهة الأمامية المستوى العلوي. محاضرة ياندكس

اختيار العمارة الصحيحة جزء أساسي من بناء خدمة أمامية. أخبرت المطور آنا كاربيليفيتش الطلاب في كلية تطوير الواجهة ما هي الهندسة المعمارية ، وما هي الوظائف التي تؤديها والمشكلات التي تحلها. من المحاضرة ، يمكنك التعرف على الأساليب المعمارية الأكثر شعبية في الواجهة الأمامية: Model-View- * و Flux.


- مساء الخير. اسمي أنيا كاربليفيتش. سنتحدث اليوم عن بنية الواجهة الأمامية ذات المستوى الأعلى.

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

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

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



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

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

مثال البناء لموضوع العمارة واضح جدًا. لكن الصورة الصحيحة أكثر إثارة للاهتمام. "العمارة هي موسيقى خدر." قال يوهان فولفجانج جوته في القرن الثامن عشر: "Architektur ist gefrorene Musik". من المحتمل أن جوته لم يكن يعرف شيئًا عن هندسة المباني ، فقد كان شاعرًا. وكان مضمونًا ألا يعرف شيئًا عن هندسة التطبيقات. لكنه عبر عن فكرة قيمة ومثيرة للاهتمام.

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

مع هذه المقدمة الإبداعية ، ننتهي ، ننتقل إلى أشياء أكثر دنيوية ، أقرب إلى ممارسة بناء التطبيقات.

ما هي العمارة ولماذا هي ضرورية؟



أولاً ، لدينا تنظيم كمية كبيرة من الرموز ، وهو أمر نواجهه في Direct ، وليس فقط في Direct ، طوال الوقت. هناك الكثير من التعليمات البرمجية التي يمكن أن تضيع فيها. نحن لا نريد أن نضيع في الكود.

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

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

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

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

وأخيرًا ، الأخطاء. كلما كانت بنيتنا أكثر قابلية للفهم والتنبؤ بها ، كلما كان من الأسهل البحث عن الأخطاء ، كلما قل الخلل.

كيف يمكن استدعاء كل هذا؟ كل هذا يمكن تسميته - مشاكل نظام معقد. التطبيق نظام معقد ؛ تساعدنا العمارة في حل مشكلة.



باختصار ، بطريقة أو بأخرى. هنا صورة المعكرونة على يميني ، وهذا ما يحدث إذا لم تتبع الهندسة المعمارية ، إذا لم تقم ببنائها ، فكر فيها وصممها. والصورة الثانية هي ما يحدث إذا تم التفكير على الأقل في الهندسة المعمارية بطريقة ما. هذا ليس Saint-Sulpice ، ولكن على الأقل مصمم أطفال ، يقف بحزم ولا ينهار. اليوم سنلعب الكثير من المنشئين أيضًا.



رسميا عن كل هذا. العمارة هي طريقة لحل مشاكل نظام معقد من خلال تجريد التنفيذ من الواجهة وتمييز السلطات بين كتل التعليمات البرمجية. علاوة على ذلك سنقوم بتحليل هذه العبارة الطويلة بالتفصيل.

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

تاريخ القضية ، عندما نشأت هذه الفكرة بشكل عام أنه يجب القيام بالعمارة. يجب أن أقول ، في وقت من الأوقات ، تم التعبير عن فكرة استثنائية للغاية في عام 1968 من قبل Edsger Dijkstra ، المبرمج الرائع. ربما يكون معروفًا بشكل أفضل كمؤلف خوارزمية Dijkstra ، البحث عن أقصر مسار في الرسم البياني. ولكن لديه في الواقع الكثير من الأفكار الخارقة لوقته. وأحدها مقال ، ثم سأعطيك إشارة إلى المواد ، يمكنك أن تقرأ ، هناك صفحتان فقط ، مقال قصير. يبدو أن "عامل التشغيل GOTO يعتبر ضارًا" ، في الترجمة "عامل التشغيل GOTO - عامل الانتقال غير المشروط - الشر". كانت الفكرة الأولى التي دعنا نقول رسميًا أننا بحاجة إلى كتابة الهندسة المعمارية ، وليس الشعرية.

في السبعينيات ، تم تطوير هذه الفكرة بالفعل من قبل Dijkstra بالتعاون مع Parnassus ، وبشكل فردي ، بشكل فردي. تم كتابة أول كتاب مفصل عن هندسة التطبيقات بشكل عام في عام 1996 بواسطة Mary Shaw و David Garlan. بعد ذلك ، في الواقع ، لم يتم كتابة مثل هذه الكتب التفصيلية حول هندسة البرمجيات على وجه التحديد بسبب النطاق ، وأن كل مجال من مجالات المعرفة له مناهجه المعمارية الخاصة به ، في مكان ما ، في مكان آخر أكثر شعبية ، شيء ، بشكل عام لا ينطبق في بعض الأماكن. وبما أن الهندسة المعمارية هي عملية إبداعية ، فلن تجد أي كتب محددة حول كيفية كتابة الهندسة المعمارية. ربما بعد عام 1996 لم يكن هناك أي شيء خاص مفصل حول هذا الموضوع.

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

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

فصل السلطة بين وحدات الكود. سنتحدث عن هذا اليوم بمزيد من التفصيل ، لماذا هذا ضروري. الفكرة هي: كل وحدة ، كل كتلة ، يجب أن تؤدي كل قطعة من التعليمات البرمجية إجراء واحد محدد ، تحمل وظيفة واحدة بالضبط. ويجب وضع هذه الوظيفة في عنوان هذه الطريقة ، الفئة ، أياً كان الأمر ، الوحدة النمطية. وحدة واحدة - وظيفة واحدة.

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

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



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



نحن نمضي قدما. كائن. والكائن هو مثال لهيكل معين. علاوة على ذلك ، مرة أخرى في OOP الكلاسيكي ، يشير ضمنيًا إلى أن الكائن هو كائن من فئة. في العالم الحديث ، في JavaScript ، التي لم تكن دائمًا لغة OOP ، وحتى الآن ليست دائمًا وفي كل مكان OOP ، نعلم أنه يمكن أن تكون هناك أشياء مجردة. بمعنى ، يمكننا إنشاء كائن ، حرفي ، لن يكون كائنًا من الفئة. ولكن هنا مثال لكيفية إنشاء كائن من فئة الأفعى. هنا لدينا ثعبان ثنائي الذيل بطول 38 ببغاوات - مقيد أفعى.



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



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



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

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

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

سنحاول الآن النظر إلى هذه الأمثلة بشكل أكثر تحديدًا.



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

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

دعونا نرى كيف يمكننا تحقيق قوة الجر والاقتران الضعيف على نقاط ما يسمى.



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

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



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



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

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

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

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



- . , . TypeScript, . , . , , , TypeScript 2.7 , ( — . .).

, User. . . User , . User , , .

printLabel. User. , User User, . User User , , . - , .

, ? , . , . , − , UserWithSurname, , printLabel. ? , , , , . - ? , . , − , . . PrintLabel . ? ? , .

, . , . , , . , if, , . , , .



printLabel, , iPrintLabel , iPhone, . - getText. User, iPrintLabel. , , , - , getText iPrintLabel, , . UserWithSurname, User, Surname getText. printLabel . iPrintLabel getText.

, , , . . , , . , , , , , iPrintLabel, , , , − . printLabel . , .

. , , , front-end, , . , front-end , , .



-? . - back-end. - API, , REST API REST. — , − -. , , - PowerPoint, . .

front-end. Front-end - . - , . , - . . . , -, . , , . .

front-end, , , , , , , .

> - ( Client-server )
> ( Component-based )
> ( Event-driven )
> REST ( Representational state transfer )
> --*( MVC , MVP , MVVM )
> ( Flux )

هذه هي الأساليب المعمارية. ذكرنا بعضهم اليوم. بنية خادم العميل ؛ مكون مكون ، أحد تنوعاته مألوف لك من رد فعل ، نأمل أن يكون مألوفًا. الحدث ، وهو أمر غريب ، مألوف أيضًا للجميع ، إنه يعتمد على جميع أنظمة تشغيل أجهزة الكمبيوتر الشخصية تقريبًا. REST ، ما نحبه في الخادم ، والأخيران ، اللذان سنتعرف عليهما بالتفصيل اليوم ، هما الأكثر الأمامية ، وما نعمل معه هو نموذج عرض * وتدفق بيانات أحادي الاتجاه.

لنبدأ بـ MV *. لماذا علامة النجمة؟ التاريخ ، كما يقولون ، مليء بالألم والغضب. ذات مرة ، في الثمانينيات ، تم اختراع النهج المعماري الرائع لـ MVC. M - نموذج ، V - مشاهدة ، C - تحكم. كان النهج مناسبًا للغاية. اخترعه بشكل عام لتطبيقات وحدة التحكم. ولكن عندما بدأت تقنيات الويب في التطور ، وعندما بدأوا جميعًا في استخدامها ، اتضح أنه في بعض الأحيان كان من الضروري ، هنا نموذج MV جيد ، ولكن وحدة التحكم لا يتم تنفيذها بالطريقة الصحيحة. ونتيجة لذلك ، كان هناك العديد من الاختلافات المختلفة في تطبيق Model-View - وهو الأمر الذي اختلط عليه الأمر في البداية بسبب حقيقة أنه كان يُطلق عليه اسم MVC. لأنه ، إذا كان هناك نموذج MV ، فالثالث هو وحدة التحكم ، فلا يهم ما قمنا بحشوه هناك.

ثم اتضح أن الناس مرتبكون ويعنيون أشياء مختلفة تمامًا بواسطة MVC. في الوقت الحالي ، ليس أكثر من عام ، بدأوا في مشاركة هذه المصطلحات بنشاط ، وجعل أسمائهم الخاصة لكل تنفيذ لهذا النهج. بطريقة أو بأخرى ، ظهر هذا MV *. رأيت أيضًا مصطلح MVW على الإنترنت ، حيث W هو أيا كان. حسنًا ، نحن ننتقل في الواقع إلى تقنيات MVC.



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



MVC ، الطريقة التي بدأ بها كل شيء تعود في عام 1980 ، Smalltalk. ولكن في هذا الشكل موجود في بعض الأطر حتى الآن. ليس في بعض الكثيرين. ما هي الفكرة؟ يعمل المستخدم مباشرة مع العرض وجهاز التحكم. يقوم بإدخال البيانات في بعض الحقول في العرض ، ويضغط على زر الإرسال وتذهب البيانات إلى وحدة التحكم. هذا تقديم نموذج. مثل هذا النموذج الصادق من خلال زر الإرسال ، مألوفًا للجميع لفترة طويلة ، آمل.

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

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



بسيط جدا. إذا كانت وحدة التحكم والطراز موجودان في النهاية الخلفية ، وكان العرض النموذجي من جانب الخادم. هذه هي الطريقة التي يتم بها ترتيب أطر عمل Ruby on Rails و ASP.NET و Django بشكل عام ، أينما تكتب نماذج من جانب الخادم ، ويأتي HTML الذي تم جمعه إلى العميل ، وتعود البيانات أيضًا ، مع احتمال كبير ، وهذا هو هذا النهج. ما هي المشاكل هنا. في تطبيق صفحة واحدة ، لا يمكن بناء مثل هذا الشيء. لدينا باستمرار بيانات على الخادم ، تذهب على الخادم ، يتم إعادة تحميل الصفحة. ثانيًا ، من غير الواضح تمامًا أين يشق التحقق من صحة العميل ، وبشكل عام ، جافا سكريبت العميل ، AJAX وكل هذا هنا؟ لأنه إذا أردنا شيئًا سريعًا ، فلا مكان. ببساطة لا يعمل في هذا النهج ، أو يعمل بحيث لا يعمل بشكل أفضل.

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

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

يجب أن أقول أنه يبدو أن العالم قد ربح وجهة النظر الثانية ، مع منطق الأعمال في النماذج. بمعنى ، يبدو أن وحدات التحكم القبيحة الغبية هذه غير مستخدمة بشكل نشط. إشارات ، يمكنك مشاهدة ما في وثائق ASP.NET ، الإطار في عام 2013 منطق الأعمال المقترحة في وحدات التحكم. وفي أحدث الإصدارات في عام 2014 - في النماذج. كانت هناك لحظة مثيرة للاهتمام عندما تغير هذا.

ما مشاكل MVC. لقد تكلمنا بهم بالفعل ، لكننا سنفعل. الاختبار لأنه ليس من الواضح كيفية تنفيذ التحقق من صحة العميل ، ولكن من الصعب ، AJAX مشدود إلى الجانب ، تحتاج إلى القيام بشيء ما. توصلوا إلى حل. كان الحل يسمى MVP ، ونعم ، يمكنك مقابلة MVP في إطار العمل مع النص أنهم MVC. على سبيل المثال ، إطار عمل Backbone MVP. حوله لفترة طويلة في الوثائق في نفس 2011-2012-2013 كتب أنه هذا إطار MVC.



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



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

ثم نرسل بصدق البيانات من خلال نموذج التقديم إلى وحدة التحكم. تذهب البيانات إلى النموذج ، النموذج يضعها في نفسها ، العمليات ، المظهر. يخبرنا أنه ، حسنا ، البيانات مقبولة ، فأنت حقا Vasya. السهم الثالث - يذهب عنصر التحكم إلى وحدة التحكم ، ويخبر النموذج وحدة التحكم أنه يرجى عرض التسمية "اسمي Vasya". وحدة التحكم تختار العرض المناسب ، وتعرض الملصق. وبيانات "اسمي فاسيا" ، السهم الرابع ، الأصفر ، النموذج يوضع هناك. السؤال هو كيف تختبر هذا؟ لقطة فقط. لا توجد طريقة أخرى. لا يوجد شيء للكتابة حتى الاختبارات الوظيفية.

الخيار الثاني ، بالفعل مع MVP. سافرنا "اسمي Vasya" ، انقر فوق موافق. السهم تحت رقم واحد ، أخضر ، - ذهبت الإدارة إلى مقدم العرض. قال العارض: تم الضغط على الزر. يبدو المقدم ، السهم رقم اثنين ، أزرق ، لاحظ أن هذا طلب بيانات. في MVP الكلاسيكي ، لا يتم إرسال البيانات من العرض إلى Presenter ، ولكن طلب من Presenter للبيانات. هذا أكثر نظافة ، لأن المقدِّم قد يعرف مسبقًا مسبقًا ، على سبيل المثال ، أنه لا يحتاج إلى بيانات ، على الرغم من كل شيء ، كل شيء سيئ.

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

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



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

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

ومع ذلك ، تم اختراع MVVM على الأقل. أيضا شيء مثير للاهتمام.



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



والعديد من الأطر حلت هذه المهام الملزمة. ما هي المزايا؟ لسنا بحاجة لكتابة كود إضافي. ويسرع حقا سرعة التطوير. ما هي عيوبه. تم تحسين الاتصال بين الموديل و ViewModel.

أي أن المشاكل تنشأ هناك على وجه التحديد بسبب الترابط القوي ، لذلك يحدث أحيانًا عدم استخدام MVVM. على سبيل المثال ، أنا شخصياً على دراية بـ MVVM في إطار i-BEM ، والذي نستخدمه أحيانًا ، وأحيانًا لا نستخدمه ، لأنه غير ملائم وضيق للغاية. ومع ذلك ، هناك ، يتم ترتيب Microsoft Silverlight بواسطة هذه التقنية ، ويقولون: جيد. لا أعرف ، لم أجربه.

لماذا حدث أنه بالإضافة إلى MVP و MVVM ، نشأ شيء آخر ، جميعكم على دراية بكلمة redux ، ولماذا كانت هناك تدفقات بيانات أحادية الاتجاه.



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

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

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



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

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

تذهب المشاهدات إلى البيانات ، ثم تبدأ لحظة مثيرة للاهتمام. في التدفق الكلاسيكي ، كما هو الحال على Facebook ، يتم إعادة رسم العرض بالكامل.



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

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

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

بعد ذلك ، هناك ميزة صغيرة في التدفق الكلاسيكي ، والتي قد تكون غير مألوفة لأولئك الذين عملوا مع Redux ، بشكل أكثر دقة ، حتى مع React ، وليس مع Redux. المشاهدات تذهب للبيانات. يذهبون إلى المتجر ويقولون: "لدي هذا الحقل ، هذا الحقل وهذا الحقل". لقد اعتدنا على حقيقة أنه ، على العكس ، كل شيء يأتي إلى وجهات النظر إذا كنت تعمل مع React أو Redux أو شيء من هذا القبيل. والنقطة السادسة إعادة رسم كاملة.

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



دعنا نتنحى ونتحدث عن React ، الذي مثل هذا ، الذي تم دمجه بنجاح كبير مع Flux ، جعل العالم الذي نعرفه الآن عندما تكون هذه التكنولوجيا أكثر شيوعًا.

نفس 2013 ، نفس 2013 ، نفس Facebook. في البداية ، تم اختراع React بشكل عام ، كملاحظة على وجهات النظر في الاختلافات MVC ، MVP. ويمكن بالفعل استخدامها هناك. ما هي قوته. أولاً ، المنزل الافتراضي ، كما قالوا بشكل صحيح ، لا يسمح بإعادة رسم المنزل الحقيقي ، لأنه عملية صعبة للغاية ، ولكن إعادة رسم المنزل الافتراضي. وفقط إذا حدث تغيير بالفعل ، فإننا نعيد رسم المكون ، ونتيجة لذلك يعمل كل شيء بشكل أسرع مما يمكن أن يكون.

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

التطبيقات المقترنة بهندسة Flux قوية. ربما يعرف الكثير من الناس أن هذا أمر قوي حقًا. ما هي بعض الأهمية التي يجب ذكرها؟ بالإضافة إلى React Redux ، هناك العديد من الحزم الأخرى. وربما تعلم أن هناك زاوية ثانية. وهو أيضًا مزيج من الإطار التفاعلي وهندسة التدفق. Vue, Flux Redux — Fluxxor, MobX . . React Redux. Vue, , , React Redux. .



? , React Redux . Vue, . — . — MVC-. . . - React Redux .

MVP/MVVM- . , — , , . single page application, multiple page application. - - . , -, - . , MVP, .

— single page application , , . . Flux React Redux, View, Angular, MobX, Fluxxor . .

. .

> MVC: Smalltalk-80 , General MVC , ASP.NET , MVC on Web
> MVP: MVP vs MVC , GUI Architecture , Backbone , Angular1
> MVVM: MS Silverlight , i-BEM
> Flux: Hexlet , Flux for stupid people , Flux official , ReactJS , VueJS
> : , «Javascript. » , ., « » , D.Garlain, M.Shaw, ”An introduction to Software Architecture” (1994), E.Dijkstra ”GOTO statement considered harmful” (1968)

MVC, MVP, MVVM . , . Flux . , , . , — . . JavaScript. . ES5, «JavaScript. » , ES6- — , , , .

, « ». . Java, . , , Flux, . MVP, — -. , . .

, , « ». , , , , , . «GOTO operator considered harmful». . , .

. . . , - , . , , Flux, , input Flux. — , , - . . , . , . .