Skip to content

4. توسعه MVC (مدل–نما–کنترل‌کننده)

یک برنامه وب اغلب دارای معماری سه‌لایه است:

Image

  • لایه [dao] دسترسی به داده‌ها را مدیریت می‌کند، که اغلب داده‌های پایدار در یک SGBD است. با این حال، این ممکن است شامل داده‌هایی از حسگرها، شبکه و غیره نیز باشد.
  • لایه [metier] منطق «کسب‌وکار» برنامه را پیاده‌سازی می‌کند. این لایه مستقل از هر نوع رابط کاربری است. بنابراین باید قابل استفاده با رابط کنسول، رابط وب یا رابط کلاینت غنی باشد. از این رو، باید امکان تست آن خارج از رابط وب، و به ویژه با استفاده از رابط کنسول وجود داشته باشد. این به طور کلی پایدارترین لایه معماری است. این لایه در صورت تغییر رابط کاربری یا تغییر روش دسترسی به داده‌های مورد نیاز برای عملکرد برنامه، تغییر نمی‌کند.
  • لایه [interface utilisateur]، که رابط (اغلب گرافیکی) است که به کاربر اجازه می‌دهد برنامه را کنترل کند و اطلاعات را از آن دریافت نماید.

ارتباطات از سمت چپ به راست جریان دارد:

  • کاربر درخواستی را به لایه [interface utilisateur] ارسال می‌کند
  • این درخواست توسط لایه [interface utilisateur] قالب‌بندی شده و به لایه [métier] ارسال می‌شود
  • اگر لایه [métier] برای پردازش این درخواست به داده‌ای نیاز داشته باشد، آن را از لایه [dao] درخواست می‌کند
  • هر لایهٔ پرس‌وجو شده پاسخ خود را به لایهٔ سمت چپ خود بازمی‌گرداند، تا اینکه پاسخ نهایی به کاربر برسد.

لایه‌های [métier] و [dao] معمولاً از طریق رابط‌های جاوا استفاده می‌شوند. بنابراین، لایه [métier] تنها از رابط(های) لایه [dao] مطلع است و از کلاس‌هایی که آن‌ها را پیاده‌سازی می‌کنند، بی‌خبر است. این امر استقلال لایه‌ها از یکدیگر را تضمین می‌کند: تغییر پیاده‌سازی لایه [dao] تا زمانی که تعریف رابط لایه [dao] بدون تغییر باقی بماند، هیچ تأثیری بر لایه [métier] ندارد. همین امر در مورد لایه‌های [interface utilisateur] و [métier] نیز صدق می‌کند.

معماری MVC (مدل–نما–کنترل‌کننده) در لایه [interface utilisateur] زمانی پیاده‌سازی می‌شود که این لایه یک رابط وب باشد:

Image

پردازش یک درخواست مشتری مراحل زیر را دنبال می‌کند:

  1. کلاینت درخواستی را به کنترلر ارسال می‌کند. کنترلر تمام درخواست‌های کلاینت را مدیریت می‌کند. این نقطه ورود به برنامه است. این C در MVC است.
  2. کنترل‌کننده C این درخواست را پردازش می‌کند. برای این کار ممکن است به کمک لایه کسب‌وکار نیاز داشته باشد. پس از پردازش درخواست مشتری، ممکن است پاسخ‌های مختلفی ایجاد شود. یک مثال کلاسیک عبارت است از:
    • یک صفحه خطا اگر درخواست نتوانسته باشد به درستی پردازش شود
    • در غیر این صورت، یک صفحه تأیید
  3. کنترل‌کننده پاسخ (= نما) را برای ارسال به کلاینت انتخاب می‌کند. انتخاب پاسخ برای ارسال به کلاینت شامل چندین مرحله است:
    • انتخاب ابجکتی که پاسخ را تولید می‌کند. این به عنوان نما (View) V شناخته می‌شود، V در MVC. این انتخاب عموماً به نتیجه اجرای عملی که کاربر درخواست کرده است بستگی دارد.
    • و در اختیار قرار دادن داده‌های مورد نیاز برای تولید این پاسخ به آن. در واقع، این پاسخ اغلب حاوی اطلاعاتی است که توسط کنترل‌کننده محاسبه می‌شود. این اطلاعات، آنچه را که به عنوان مدل نما M (M در MVC) شناخته می‌شود، تشکیل می‌دهد.
    • بنابراین، گام سوم شامل انتخاب یک نمای V و ساخت مدل M مورد نیاز برای آن است.
  4. کنترل‌کننده C به نمای انتخاب‌شده دستور می‌دهد تا خود را نمایش دهد. این معمولاً شامل فراخوانی یک متد خاص از نمای V است که مسئول تولید پاسخ برای مشتری است. در این سند، از اصطلاح «نمای» برای اشاره به هم شیئی که پاسخ را برای مشتری تولید می‌کند و هم خود پاسخ استفاده خواهیم کرد. مستندات MVC در این مورد صریح نیست. اگر قرار بود پاسخ «ویو» نامیده شود، می‌توانستیم به ابجکتی که این پاسخ را تولید می‌کند، «تولیدکننده ویو» بگوییم.
  5. ژنراتور نما V از قالب M که توسط کنترل‌کننده C آماده شده است، برای inicialize کردن بخش‌های پویا در پاسخی که باید به کلاینت ارسال کند، استفاده می‌کند.
  6. پاسخ به کلاینت ارسال می‌شود. شکل دقیق آن به تولیدکننده نما بستگی دارد. این پاسخ می‌تواند یک جریان HTML، PDF، اکسل و غیره باشد.

روش‌شناسی توسعه وب MVC لزوماً به ابزارهای خارجی نیاز ندارد. بنابراین می‌توان یک برنامه وب جاوا را با معماری MVC با استفاده از یک JDK ساده و کتابخانه‌های پایه توسعه وب توسعه داد. یک رویکرد که می‌توان برای برنامه‌های ساده استفاده کرد به شرح زیر است:

  • کنترلر توسط یک سروِلت واحد مدیریت می‌شود. این «C» در MVC است.
  • تمام درخواست‌های کلاینت شامل یک ویژگی «action» هستند، برای مثال (http://.../appli?action=liste).
  • بسته به مقدار ویژگی «action»، سرولت یک متد داخلی از نوع [doAction(...)] را اجرا می‌کند.
  • متد [doAction] اقدام درخواستی کاربر را انجام می‌دهد. برای این کار، در صورت لزوم از لایه [métier] استفاده می‌کند.
  • بسته به نتیجهٔ اجرا، متد [doAction] تعیین می‌کند که کدام صفحهٔ JSP نمایش داده شود. این نمای V از مدل MVC است.
  • صفحه JSP حاوی عناصر پویایی است که باید توسط سرولت فراهم شوند. متد [doAction] این عناصر را فراهم می‌کند. این مدل برای نما است، حرف M در MVC. این قالب اغلب در زمینه درخواست (request.setAttribute("key", "value"))، یا به ندرت در زمینه جلسه یا برنامه قرار می‌گیرد. یک صفحه JSP به هر سه زمینه دسترسی دارد.
  • متد [doAction] با ارسال جریان اجرایی به صفحهٔ منتخب JSP، نما را نمایش می‌دهد. برای این کار، از یک عبارت به شکل [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)] استفاده می‌کند.

این الگوی طراحی، MVC، با نام الگوی «فرانت کنترلر» یا الگوی کنترل‌کنندهٔ واحد شناخته می‌شود. یک سرولت واحد تمام درخواست‌های همهٔ کاربران را مدیریت می‌کند.

بیایید به معماری اپلیکیشن وب قبلی بازگردیم:

Image

این معماری با معماری چندلایه زیر مطابقت دارد:

Image

در واقع تنها یک لایه وجود دارد: لایه رابط کاربری وب. به طور کلی، یک برنامه وب مبتنی بر سرولت‌ها و صفحات MVC معماری زیر را خواهد داشت:

Image

برای برنامه‌های ساده، این معماری کافی است. وقتی چند برنامه از این نوع را نوشتید، متوجه می‌شوید که سرولت‌های دو برنامهٔ مختلف:

  1. از همان مکانیزم برای تعیین اینکه کدام متد [doAction] باید برای رسیدگی به عملی که کاربر درخواست کرده است اجرا شود، استفاده می‌کنند
  2. در واقع تنها در محتوای این روش‌ها [doAction] تفاوت دارند

بنابراین بسیار وسوسه‌انگیز است که:

  • پردازش (1) را در یک سروِلت عمومی که از برنامه‌ای که از آن استفاده می‌کند بی‌خبر است، عاملی‌سازی کرد
  • واگذاری پردازش (2) به کلاس‌های خارجی، زیرا سروِلت عمومی نمی‌داند در کدام برنامه در حال استفاده است
  • ارتباط دادن اقدام درخواستی کاربر به کلاسی که باید آن را پردازش کند، با استفاده از یک فایل پیکربندی

ابزارهایی که اغلب «چارچوب» نامیده می‌شوند، برای فراهم کردن این قابلیت‌ها برای توسعه‌دهندگان پدید آمده‌اند. قدیمی‌ترین و احتمالاً شناخته‌شده‌ترین آن‌ها Struts (http://struts.apache.org/) است. جاکارتا استراژ (Jakarta Struts) پروژه‌ای از بنیاد نرم‌افزار آپاچی (Apache Software Foundation) (www.apache.org) است. این فریم‌ورک در آدرس (http://tahe.developpez.com/java/struts/) توضیح داده شده است.

چارچوب اسپرینگ (http://www.springframework.org/)، که اخیراً ظهور کرده است، ویژگی‌های مشابهی با استروتس ارائه می‌دهد. استفاده از آن در چندین مقاله (http://tahe.developpez.com/java/springmvc-part1/) شرح داده شده است.

اکنون مثالی از معماری MVC مبتنی بر سرولت‌ها و صفحات JSP ارائه می‌دهیم.