PHP MVC (بدون إطار) ، هل يجب أن أتصل بالكثير من الطرق في وحدة التحكم أو النموذج الخاص بي؟

Question

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

خلفية صغيرة في تطبيقي: أنا أستخدم Smarty كمقدمي ونهج موجه نحو الكائن. يبدو بسيطًا بما فيه الكفاية ، لكنني أحاول اكتشاف سؤال "ما هو النموذج" في كل مكان.

إذا ألقيت نظرة على بعض البرامج التعليمية والأطر ، فيبدو أنها تعتبر النموذج فئة صارمة يرث أساليب DAL من فئة مجردة ، مع تعريف إضافي قليلاً في الفئة نفسها حيث تختلف احتياجات البيانات الخاصة بك من كائن إلى كائن. على سبيل المثال ، قد أرى شيئًا مثل $ productmodel-> الحصول على (5) يعيد مجموعة من 5 منتجات من قاعدة البيانات. فماذا لو كنت بحاجة إلى الاستعلام عن نماذج متعددة؟ هل أقوم بتخزين جميع البيانات في وحدة التحكم أو صفيف وأمر ذلك إلى العرض؟ ثم إذا كنت أتصل ديناميكي وحدة التحكم الخاصة بي ، فكيف يمكنني استمرار البيانات الفريدة لوحدة التحكم اللازمة لتقديم العرض؟ يبدو هذا سيئًا ، خاصةً لأنه يجب عليّ بعد ذلك أن أنقل في أشياء مثل "Controlname" و "ControlRdata" و My View :: Render () تنفخ بشكل كبير مع المعلمات ، إلا إذا مررت في وحدة التحكم نفسها. ربما أفتقد شيئًا هنا.

دعنا نقول أنني أريد أن أجعل تسجيل دخول يستفسر عن جدول المستخدمين. تسجيل الدخول هو نموذج أو وحدة تحكم ، اعتمادًا على بعض التطبيقات التي رأيتها عبر الإنترنت. بعض التطبيقات (سأسمي هذه الطريقة 1) قم بعمل logincontroller باستخدام method login () قد تقوم بمقارنة بين $ _post وما تم إرجاعه من مثيل نموذج المستخدم $-> الحصول على (1) لمعرفة ما إذا كان المستخدم قد تم التحقق منه . أو ربما يكون تسجيل الدخول () طريقة في وحدة تحكم افتراضية. على الجانب الآخر ، فإن التنفيذ (طريقة التنفيذ 2) يشبه المزيد من نهج جملة من شأنه أن يجعل نموذج تسجيل الدخول ويعلن كل الإجراءات الموجودة داخل ذلك. ثم سيتم إرجاع أي بيانات تحتاج إلى تعيين للعرض من تلك الطرق. لذا فإن تسجيل الدخول-> تسجيل الدخول () سيتحقق فعليًا من النشر ، ومعرفة ما إذا كانت هناك تطابق ، وما إلى ذلك. من المحتمل أن يتم إنشاء نموذج للمستخدم داخل طريقة النموذج هذه.

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

مشاعري حول 2: لا تجعل إجراء أفعال ليست أساليب نموذجية. إذا كنت أرغب في الذهاب إلى جذر موقعي ، فيجب علي إنشاء نموذج فهرس أو شيء يبدو مبالغًا فيه من أجل الحصول على نموذج يمرر البيانات إلى العرض. أيضا ، لا يبدو أن هذا نهج شائع للغاية. ومع ذلك ، فإنني أحب ذلك أكثر لأنه يمكنني فقط القيام بعرض :: عرض (mymodel-> func ()) والتأكد من أن البيانات سيتم تمريرها بالطريقة التي أحبها دون الحاجة دمج آلاف الاستعلام نتائج معا.

لقد خاضت الكثير من الحجج الدينية حول هذا الأمر وأريد أن تعرف ما تفكر فيه يا رفاق.

Answer 1

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

للحصول على وحدة تحكم تسجيل الدخول ، قد أقوم بإنشاء شيء مثل ...

ما بعد URI: http://example.com/login/authenticate

LoginController extends ParentController {
  public function authenticate() {
    $credential_model = $this->getModel('credentials');
    // Obviously you should sanitize the $_POST values.
    $is_valid = $credential_model->isValid($_POST['user'], $_POST['email']);
    $view = $is_valid ? 'login_fail.php' : 'login_success.php';
    $data = array();
    $data['a'] = $a;
    // .. more vars
    $this->view->render($view, $data);
  }
}

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

أما هذا ...

ثم إذا كنت أتصل ديناميكي وحدة التحكم الخاصة بي ، فكيف يمكنني استمرار البيانات الفريدة لوحدة التحكم اللازمة لتقديم العرض؟

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

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

Answer 2

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

في النهاية ، مهما كان الأمر الأكثر منطقية بالنسبة لك ، وأيًا يسهل عليك تصور تطبيقك وإضافته بسرعة أو تغييره ، سيكون أفضل خيار لك.

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

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

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

---

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

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