نحن لانطبق MVC هكذا !

الأربعاء-10-2010

كنت اقرا عن بعض انواع Design Pattern بالتحديد Milti-Tier Architecture واللذي يعتمد علي ثلاث طبقات متتالية وكل شئ يمر من خلال الطبقة الثانية (Logic) والتي تكافئ Controller في MVC لكن يبدو اني ممافهمت في كل هذه الامور حتي الان اننا لانطبق MVC بشكل جيد

فـ MVC ليس طبقات بل مثلث كل اضلاعة متصلة ببعض , مثلا لو احتاج View (وهوما يمثله Presentation في Mulitier Architecture ) يمكن أن يطلب اي شئ من Model (يمثله Data في Multitier Architecture ) ولكن من ملاحظتي لما يفعله الجميع هو ان اي شئ يحتاجه View نقوم بتمريره له عن طريق Controller ولا نقوم بطلبه مباشرة كما من المفترض ان يحدث في منطق MVC

Advertisements

MVC

الثلاثاء-10-2009

اليوم سوف بتكلم عن طريقة تسمي  Thin Controller , لا اعرف هل اقول طريقة أم نظرية , تابع المقال وصنفها كما شئت

كما نعرف ان MVC يتكون من Model و View و Controller ولكن بسبب اعتياد الجميع على النمط العادي من البرمجة يدفعنا أحياننا الي وضع كل البيض فى نفس السلة ووضع كل شئ داخل Controller  ولكن فى الحقيقة يجب معرفة انك بهذا لاتطبق MVC فى تطبيقاتك حتي لو كنت تعمل مع فرام ورك

Model : هو ذلك الجزء من تطبيقك اللذي يتعامل مع البيانات بكل أنواعها وليس فقط قواعد البيانات , مثلا اذا كنت تتعامل مع RSS فيجب ان يهتم الـ Model بكل شئ يتعلق بها ولو كنت تستخدم SOAP مثلا فيجب ان يهتم بها ايضا

بالاضافة الي ذلك اي شئ يتعلق بقوانين التطبيق توجد هنا , مثلا ان كان لديك دالة تقوم بفحص اماكنية المستخدم من رفع ملف مثلا او اذا كان تجاوز الحد الاقصي فهي يجب ان توجد فى Model وليس فى Controller

كل هذا يجعل عملية انتقالك الي Framework اخر -على سبيل المثال – سهلة , مثلا لو كنت تستخدم Symfony وتريد نقل المشروع باكمله الي Zend فلن تضطر الي اعادة كتابة كل شئ بل ستقوم بنقل الـ Model فقط ولأن الـ Controllerصغير لن يكون هناك الكثير من العمل

Controller: لا أجد وصف له سوي  أنه تعبير حي عن خطة سير البرنامج – flow chart – فقط لا أكثر بدون ان يزيد عليه شئ

View : هو يتعامل مع كل شئ يتعلق بالعرض , وليس شرطا أن يكون كل شئ يحتاجه يجب أن يتم تمريره له عن طريق Controller , بل على العكس يجب أن يكون قادر على التعامل مع Model مباشرة ويمكنك مثلا عمل View Helpers – مساعدات للعرض – لكي تقوم بعلم تلك الاشياء