معادل های موجود در Spring MVC – Spring MVC

Spring برای هر یک از مفاهیم مدل، view، کنترلر و dispatcher معادلی فراهم می کند که می توانند به طور کامل با استفاده ویژگی تزریق وابستگی[۱]موجود در Spring با کد لایه میانی شما یکپارچه شوند.

اجرای عملیات در کنترلرها

مولفه هایی که بر روی پردازش های مربوط به وب (و در نهایت کارها را به لایه میانی انتقال می دهند) کنترلر نامیده می شوند. Spring شامل انواع کنترلرهایی است که هر یک به هدف حل یک مشکل خاص در برنامه های کاربردی وب، مانند مدیریت فرم و یا انجام اتوماتیک یک مجموعه امور طراحی شده اند. بیشتر کنترل هایی که Spring فراهم می کند، از اینترفیس org.springframework.web.servlet.mvc.Controller مشتق می شوند. در این رابط کاربری تابع زیر وجود دارد:

 

یک کنترلر به دو روش یک درخواست را مدیریت می کند: یا از طریق برگرداندن نتیجه ای از نوع ModelAndView مربوطه (حالت عادی)، و یا در صورتی که کنترلر، خود، پاسخ درخواست را به صورت یک نمونه ServletResponse تولید و ارسال کرده باشد، برگرداندن مقدار null. روش دوم به طور کلی روش خوبی در نظر گرفته نمی شود، اما گاهی اوقات استفاده از آن اجتناب ناپذیر است. Spring چندین نمونه پیاده سازی کنترلر را فراهم می کند، که بسیاری از آنها با HttpServletResponse کار نمی کنند. به عنوان یک برنامه نویس، شما احتمالا هیچ زمانی نیاز به کار با پاسخ servlet نخواهید داشت، زیرا ModelAndView تمام کنترل هایی را که شما نیاز دارید به شما می دهد. اما اگر زمانی وضعیتی پیش آمد که شما نیاز به انعطاف پذیری بیشتر داشته باشید، می توانید اینترفیس Controller را پیاده سازی و یا یکی از کنترلرهای موجود در ساختار سلسله مراتبی Controller را extend کنید (مانند AbstractController).

برگرداندن یک نمونه از ModelAndView

کلاس ModelAndView به شما اجازه می دهد تا پاسخ مشخصی، بر اساس تصمیماتی که توسط کنترل گرفته اید برای مشتری ارسال کنید. این شی هم دارای یک نمونه از ارائه ای است که مشتری خواهد دید و هم شامل مدلی است که برای نمایش ارائه مورد استفاده قرار می گیرد. اشیاء ModelAndView را می توان به روش های مختلفی ایجاد کرد. ساختار زیرین مدل java.util.Map است. یک سازنده مناسب به شما اجازه می دهد تا یک نقشه مدل را مستقیما مشخص کنید، و یا شما می توانید یک مدل خالی ساخته و اشیاء را از طریق methodهای کلاس ModelAndView به آن اضافه کنید:

 

درخواستی که در Spring به یک کنترلر ارسال شده است، همیشه باید به یک نتیجه از نوع ModelAndView تبدیل شود، مگر اینکه شما درخواست را مستقیما مدیریت کرده و نخواهید که dispatcher نتیجه پردازش یک view را به کاربر بازگرداند.

ممکن است این سوال به وجود آید که چرا Spring نوع ModelAndView خود را دارد. عناصر مدل به map موجود در این نوع اضافه می شوند، و به نظر می رسد اضافه کردن عناصر به طور مستقیم به HttpServletRequest (به عنوان ویژگی درخواست) همان هدف را دنبال می کند. اگر به یکی از نیازهایی که Spring دارد نگاهی بیاندازیم دلیل انجام این کار واضح خواهد شد: کنترلر باید تا حد ممکن نسبت به view خنثی باشد، به عبارت دیگر ما مایل هستیم قادر باشیم از فن آوری های نمایش مختلف به راحتی استفاده کنیم و حتی به HttpServletRequest نیز محدود نباشیم. این view می تواند، برای مثال، XSLT باشد که در آن، مدل، درون یک سند XML قرار می گیرد و با استفاده از یک XSL style sheet ارسال می شود. قابلیت آزمودن نیز با ایجاد انتزاع از Servlet API اندکی راحت تر می شود.

بازگرداند یک view

برای تکمیل توضیحات در مورد مراحل، باید در مورد رابط View و مفهوم view resolver نیز توضیح داد، هر چند شما احتمالا هرگز مستقیما View را پیاده سازی نکنید. پیاده سازی های رابط View مسئول ارائه پاسخ به مشتری، اغلب چیزی شبیه به یک صفحه HTML هستند. رابط View دقیقا یک متد را تهیه کرده که بیان کننده مسئولیت آن نیز است:

 

معمولا پیاده سازی رابط View، به جای کد نویسی جاوا، تفسیر کردن یک قالب مانند JSP و یا Velocity است که برای تولید محتوای واقعی مورد ارزیابی قرار می دهد. بنابراین پیاده سازی های View، اغلب عمومی هستند و برای استفاده در قالب های مختلف پارامتر بندی شده اند.

Spring از یک استراتژی با نام logical view names یا نام نمایش منطقی برای نمایش تفسیر یک view استفاده می کند. Viewها با کمک نام معین می شوند، و از این طریق، کنترلرها دیگر نیاز ندارد شناسه های مخصوص تکنولوژی مورد استفاده را دقیقا مشخص کنند. یک view resolver مسئول دستیابی به یک تکنولوژی خاص view – و شی ارائه مخصوص، بر اساس نام نمایش منطقی است. استفاده از تکنولوژی view مستقل نام نمایش منطقی به همراه یک استراتژی view resolver جدایی کاملی بین کنترلری که مدل ها را برمی گرداند و viewهایی که مدل را پردازش می کنند فراهم می کند. برای انتقال از یک تکنولوژی view به دیگری، نیازی به تغییر در هیچ کنترلر و یا کد زیربنایی نیست. تنها پیکربندی و فایل های مخصوص تکنولوژی view مانند JSPs و یا قالب های Velocity تغییر خواهند کرد.

تکمیل تصویر: DispatcherServlet

زمانی که ما مفاهیم کلی web MVC را مطالعه می کردیم، در مورد درخواست هایی که باید به کنترلرهای ارسال شوند صحبت کردیم. معمولا، فریم ورک های وب ارسال درخواست HTTP را با استفاده از یک Front Controller Serlvet انجام می دهند. Spring نیز اینگونه عمل می کند. نقطه ورودی اصلی برای تمام درخواست های کاربر، DispatcherServlet است. این ابزار درخواست را بررسی کرده و تعیین می کند که کدام کنترلر را برای اجرای آن فراخوانی کند. DispatcherServlet گردش کار مرتبط با اجرای یک درخواست را مدل می کند. این ابزار درخواست ها را به کنترلر ارسال می کند و بر روی پردازش پاسخ، بر اساس اطلاعات مدل و view دریافت شده از سمت کنترلر نظارت دارد. تمام این کارها با استفاده از مجموعه ای از ویژگی های دیگری Spring web MVC انجام می شود که با آنها آشنا خواهیم شد.

مولفه های زیربنایی

حال که در مورد مفاهیم اولیه مرتبط با پیاده سازی یک برنامه تحت وب با استفاده از Spring web MVC، اطلاعاتی به دست آوردیم اجازه دهید به جزئیات بپردازیم.

پیاده سازی یک برنامه تحت وب با استفاده از Spring web MVC، شامل ساخت و راه اندازی کنترلرها، ارائه viewها و داده ها مورد نیاز برای نمایش در viewها است. تمام این موارد با ترکیب یک DispatcherServlet و یک ApplicationContext به یکدیگر متصل می شوند. DispatcherServlet یک دروازه سرور فراهم می کند و به عنوان مدیر برای مدیریت گردش کار مبتنی بر درخواست و پاسخ وابسته به HTTP عمل می کند. یک نوع خاص زمینه، به نام WebApplicationContext با servlet یکپارچه شده و مدیریت تمام مؤلفه های مربوط به وب را از جمله کنترلرها، viewها، نگاشت های بین آدرس ها، و interceptorها بر عهده دارد. تفاوتی چندانی بین WebApplicationContext و ApplicationContext وجود ندارد، و به عنوان یک کاربر، به سختی متوجه تفاوت ها خواهید شد.

شکل زیر معماری پایه ای یک برنامه تحت وب Spring را نشان می دهد.

mvc-context-hierarchy

[۱] Dependency Injection

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *