سؤال

عند قراءة وثائق Kohana ، اكتشفت أن الفرق الرئيسي في الإصدار 3.0 هو أنه يتبع نمط HMVC بدلاً من MVC كما يفعل الإصدار 2.x. الصفحة حول هذا في مستندات كوهانا واللاحقة الموجودة على ويكيبيديا لم تعطيني فكرة واضحة حقًا.

لذلك سؤال: ما هو نمط HMVC وكيف يختلف عن MVC؟

هل كانت مفيدة؟

المحلول

كتب Sam de Freyssinet (أحد مطوري Kohana) بدلاً من ذلك مقالة متعمقة حول HMVC, ، ما هو ، وكيف يمكن استخدامه.

الرابط ميت: رابط جديد - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

نصائح أخرى

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

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

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

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

وذلك في حين مقالة Sam de Freyssinet Techportal عند التوسع مع HMVC أمر مثير للاهتمام للتفكير فيه ، ليس المكان الذي سيحصل فيه 90 ٪+ من الأشخاص الذين يستخدمون أطر HMVC على فوائد حقيقية وعملية وليوم.

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

انظر أيضا هذه الإجابة: https://stackoverflow.com/questions/115629/simplest-php-prouting-framework/120411#120411

في Kohana ، على الأقل ، فإن طلب HMVC هو طلب HTTP الذي يتم خدمته "داخليًا": بدلاً من إصداره عبر الشبكة ، يتم توجيهه وإرساله ومعالجته بواسطة الإطار نفسه. إن تشابه أسماء "HMVC" و "MVC" أمر مربك لأنه يشير إلى وجود علاقة أساسية بين المصطلحات التي لا توجد في الواقع: أحدهما ليس متغيرًا بسيطًا أو تعديلًا للآخر ، فهي أشياء مختلفة تمامًا. (يوصف HMVC أيضًا باسم AJAX بدون طلب HTTP من جانب العميل.) تركيز Kohana على ، ودعم "HMVC" يعني أن الإطار لديه دعم قوي للهندسة المعمارية الموجهة للخدمة HTTP.

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

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

[تحديث أبريل 2011 ، مارس 2012: توسعت على الإجابة ردا على التعليقات.

HMVC هو وحدة تحكم عرض النموذج الهرمي. في MVC العادي ، كل كائن واجهة المستخدم الرسومية لديه mvc.but لا توجد أي علاقة بين كائن واجهة المستخدم الرسومية الأصل وكائن واجهة المستخدم الرسومية للأطفال على عكس HMVC. في HMVC ، يمكن لكل كائن واجهة المستخدم الرسومية إمكانية الوصول إلى كائناته الفرعية ويمكن لكل كائن من الأطفال الوصول إلى كائنه الأم.

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

للحصول على تفاصيل الوصف الرجاء النقر هنا

رابط جديد هو هذا العنوان

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top