DispatcherServlet – Spring MVC

org.springframework.web.servlet.DispatcherServlet نقطه ورودی اصلی هر یک از درخواست هایی است که Spring MVC دریافت می کند. مانند هر servlet دیگر، این servlet نیز باید در فایل web.xml اعلان شود. در نتیجه این کار، این servlet به جهان خارج متصل می شود (بدین معنی که برنامه های کاربردی با استفاده از پروتکل HTTP می توانند به این servlet دسترسی داشته باشند). این servlet می تواند به گونه ای پیکربندی شود که نیازهای ما را برطرف کند و دارای پارامترهایی برای مقداردهی اولیه است برای کنترل رفتار آن است. این پارامترها در جدول زیر نمایش داده شده اند.

تقریبا در همه شرایط بجز شرایط استثنایی مقادیر پیش فرض پارامتر های DispatcherServlet مناسب خواهند بود. علاوه بر این، شما معمولا برای اجرای یک رفتار خاص، به پیاده سازی یک زیر کلاس از DispatcherServlet نیاز ندارید. در مورد Spring MVC، همانند Spring عمومی، فریم ورک نقاط گسترشی را در قالب رابط هایی که شما می توانید پیاده سازی کنید فراهم کرده است.

به طور معمول شما نباید کلاس های زیرساخت Spring را برای سفارشی سازی رفتار آن، گسترش دهید. زیرا این کار باعث ایجاد وابستگی غیر ضروری کد شما به فریم ورک می شود.

پارامتر توضیح مقدار پیش فرض

contextClass

نوع WebApplicationContext مورد استفاده

XmlWebApplicationContext

namespace

نام دامنه مورد استفاده WebApplicationContext

[name of servlet]-Servlet

contextConfigLocation

پارامتر مشخص کننده مکان پیش فرض WebApplicationContext(s)

/WEB-INF/[namespace].xml

publishContext

آیا ApplicationContext در ServletContext منتشر شود یا به عبارت دیگر برای سایر servlet ها در دسترس باشد

True

هر DispatcherServlet تعریف شده در یک برنامه تحت وب Spring یک WebApplicationContext مخصوص به خود را دارد. همانطور که قبلا مشاهده شد، به طور پیش فرض، فضای نام آن شامل نام servlet است و دامنه آن محدود به درخواست هایی است که تنها به این servlet نگاشته شده باشند؛ به عبارت دیگر servletهای دیگری که یک درخواست را دریافت کنند قادر نخواهد بود از اشیاء تعریف شده در WebApplicationContext استفاده کنند.

برای اینکه قابلیت های مشترک در بین چند servlet در داخل یک برنامه به اشتراک گذاشته شوند، در زمان مقدار دهی اولیه، ابتدا dispatcher servlet پیکربندی اولیه خود را بازیابی می کند (عناصر پارامتر init-param از web.xml)، و به دنبال یک ApplicationContext عادی می گردد که توسط ContextLoaderListener یا ContextLoaderServlet مقداردهی اولیه شده باشد. به عنوان مثال این زمینه ممکن است شامل سرویس های لایه میانی ای باشد که شما قصد استفاده از آنها را در کنترلر خود دارید. اگر شما از پیش فرض های Spring استفاده می کنید، در این صورت ContextLoader وب گرا نیز باید در ServletContext برنامه تحت وب واقع شود. اگر چنین ApplicationContext پیدا شود، در این صورت این شی پدر WebApplicationContext خواهد بود که به طور خاص به dispatcher servlet متصل خواهد شد.

برنامه های تحت وب Spring نمی توانند بدون یک WebApplicationContext وجود داشته باشند. زمانی که از تنظیمات پیش فرض DispatcherServlet استفاده می کنید، باید یک فایل XML تهیه کنید که beanها را درون خود تعریف کرده باشد، و آن را در دایرکتوری WEB-INF / ساختار WAR خود قرار دهید، و نام آن را nameOfServlet]-Servlet] بگذارید (مگر اینکه به صورت پیش فرض نام دیگری مشخص کرده باشید).

همانطور که قبلا ذکر شد، ممکن است DispatcherServletsهای متعددی برای یک برنامه تحت وب ایجاد شده باشد. این رویکرد نتیجه مشابه ماژول های Strut خواهد داشت. به این که beanهای خود را کجا قرار دهید کاملا دقت کنید. زمانی که زمینه برنامه پدر توسط ContextLoaderListener بارگذاری می شود، xxx-servlet.xml باید همیشه حاوی beanهای مرتبط با وب سایت را داشته باشد. به عنوان مثال، این فایل باید حاوی beanهای لایه میانی، مانند data sources، اشیاء دسترسی به داده ها، و اشیاء خدمات باشد.

یک نمونه از اعلان DispatcherServlet در فایل web.xml در ادامه آمده است. این servlet مقادیر پیش فرض را برای همه پارامترهای پیکربندی استفاده کرده است و در نتیجه زمینه برنامه کنترلر و سایر اشیاء وب را از درون فایل WEB-INF/sample-servlet.xml / بارگذاری می کند.

 

برای نشان دادن چگونگی تغییر رفتار یک DispatcherServlet، شما می توانید دو فایل XML داشته باشید، که با هم یک WebApplicationContext را تعریف می کنند. برای این کار، شما باید init-param را در اعلان servlet اضافه کنید. مکان های متعدد را می توان با استفاده از کاما، سمی کالن، و یا فاصله مجزا کرد.

 

در ادامه، شما باید به servlet container بگویید که می خواهید چه درخواست هایی از برنامه وب Spring شما توسط این DispatcherServlet مدیریت شوند. معمولا شما تعدادی از پسوندهای فایل را به DispatcherServlet نگاشت می کنید، برای مثال تمام فایل هایی که به .view و .edit ختم می شوند، به کنترلرهای view و فرم نگاشته می شوند. درخواست های رسیده به DispatcherServlet با استفاده از Servlet mapping نگاشته می شوند. نمونه servlet mapping که در ادامه آمده است به servlet container می گوید که همه درخواست هایی که به .view و .edit موجود در مسیر secure / ختم می شود را به DispatcherServlet نگاشت کند. توجه داشته باشید که این قدم از تنظیمات به مورد نیاز مشخصات servlet است، و Spring به آن نیازی ندارد.

 

URLهای ذکر شده به وضوح به آنچه آنها به دنبالش هستند اشاره می کند: ویرایش ومشاهده. URLهایی خوش تعریف باشند و به شکلی منطقی گروه بندی شده باشند، علاوه بر این جدا سازی بر اساس عملکرد، فواید بیشتری برای برنامه کاربردی دارند. در یک پروژه، یکی از برنامه نویسان با وضعیت مواجه شد که در آن او نیاز داشت یک decorator خاص با نام SiteMesh را بر روی همه درخواست، به جز آنهایی که باید در یک پنجره جدید باز شوند (pop-up) اعمال کند. با استفاده از یک گروه بندی واضح و خوش تعریف، او به راحتی توانست decorator خود را بر روی تمام درخواست ها، به جز آنهایی که به popup. ختم می شدند اعمال کند.

نه Spring و نه Servlet API شما را به استفاده از پسوند و یا الگوهای خاصی در آدرس ها مجبور نمی کنند. شما برای استفاده از هر نوع URL آزاد هستید. حتی در Spring، تطبیق کنترلرها صرفا به آدرس ها وابسته نیست – قابلیتی که اکثر فریم ورک های وب پشتیبانی نمی کنند. به عنوان مثال، شما می توانید بر اساس پارامترهای تعریف شده، و یا حتی یک جلسه HTTP یک نگاشت را تعریف کنید.

به یاد داشته باشید که استفاده از پسوندهایی مانند jsp. یا asp. و یا حتی do. که در بسیاری از برنامه های کاربردی وب جاوا استفاده می شود به هکرها می گوید که از چه تکنولوژی استفاده می کنید. اگر شما نمی توانید به یک پسوند معقول برسید، به جای آن از html. استفاده کنید.

پس از آنکه DispatcherServlet را اعلان و احتمالا آن را با استفاده init-paramها اصلاح کردید، تقریبا کار شما با web.xml به پایان می رسد. پس از آن، شما باید یک WebApplicationContext حاوی کنترلرها و احتمالا سایر مؤلفه های مربوط به وب مانند view resolver، مدیر استثناها، و resolverهای زبان را تعریف کنید. اگر مقادیر پیش فرض شما را راضی می کند، در این صورت بسیاری از این تعاریف اختیاری هستند. با این حال، شما با تعریف آنها می توانید به درجه بالایی از سفارشی سازی فریم ورک MVC دسترسی پیدا کنید.

همانطور که گفته شد مقدار دهی اولیه یک زمینه برنامه جداگانه شامل سرویس های لایه میانی، باید با استفاده از (ContextLoaderServlet(Listener انجام پذیرد. قطعه ای از کد مربوط به این مقداردهی در اینجا آورده شده است.

 

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

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