روال بررسی یک درخواست جدید – Spring MVC

شکل های زیر روال بررسی یک درخواست را به صورت گرافیکی نشان داده اند.

Workflow Involved with Handling Requests 1 Workflow Involved with Handling Requests 2

فاز اول تعیین مسیری است که باید درخواست را پاسخ دهد. این مسیر شامل صفر یا بیشتر interceptor و دقیقا یک handler است.

یک handler مولفه ای است که درخواست را پردازش می کند – به عبارت دیگر، اقدام مناسبی را با توجه به درخواست انجام می دهد. به طور خاص، handler مولفه ای است که مدل را آماده می کند.

اصطلاحات handler و کنترلر اغلب به جای یکدیگر استفاده می شود. اگر شما از ساختار کنترلی Spring استفاده می کنید تفاوت واقعی بین این دو وجود ندارد. هرچند در موارد نادر، ممکن است شما نیاز داشته باشید زیرساخت کنترلی خود را استفاده کنید. نکته مهمی که باید به یاد داشته باشید این است که کنترلر و یا handler برای آماده سازی یک مدل، با استفاده از اطلاعات درخواست ورودی به سرولت استفاده می شود.

interceptorها نیز مولفه های درگیر در مسیر اجرای یک درخواست هستند. آن ها برای اجرای یک قطعه کد قبل و بلافاصله پس از کار کنترلر استفاده می شوند. interceptorها امکان خوبی هستند، چرا که به شما اجازه افزودن یک روال اضافی در مسیر اجرا را، بدون تاثیر بر روی کنترلر می دهند. interceptorها تا حدی سرولت فیلترها را شبیه سازی می کنند؛ آنها همچنین قادر هستند درخواست را تغییر داده و یا رفتار متفاوتی را نشان دهند. سرولت فیلترها بخشی از استاندارد سرولت ۲٫۳ هستند. آنها از این بابت نسبت به HandlerInterceptorها متفاوت هستند که فیلترها در سطح استقلال بیشتری از چارچوب عمل می کنند و اجازه تعامل با درخواست و پاسخ را در سطح پایین تری می دهند. HandlerInterceptorها از حضور خود در Spring آگاه هستند و رفتارهایی را نشان می دهند که به فریم ورک وابسته است، مانند اصلاح یا تغییر ModelAndView یا بررسی یک ApplicationContext. همانطور که برنامه نویسی جنبه گرا تا حد زیادی درجه جدایی در طراحی نرم افزار را بهبود می بخشد، HandlerInterceptors برای اضافه کردن یک رفتار به یک درخواست، بدون تاثیر بر روی مولفه واقعی پردازش درخواست استفاده می شود.

پس از آنکه مسیر پردازش درخواست تعیین شد، به هر یک از inspectorهای تعیین شده برای بررسی درخواست ورودی فرصت داده می شود. هر یک از inspectorها می توانند تصمیم بگیرند فریم ورک درخواست را بیشتر پردازش نکند. این زمانی مفید است که، برای مثال، یک inspector برای اهداف امنیتی کار کند. اگر یک inspector  از پردازش بیشتر درخواست جلوگیری کند، فریم ورک اجازه اجرای کنترلر (تعیین شده توسط مسیر اجرا) را نمی دهد.

اگر هیچ یک از inspectorها جریان رو به جلوی زنجیره اجرا را متوقف نکنند، Spring کنترل را به کنترلر خواهد داد و اجازه می دهد درخواست را پردازش کند.

پس از آنکه درخواست توسط inspectorها (در صورت وجود) پیش پردازش شد، Spring کنترل را به کنترلر می دهد. این کنترلر باید یک شی از نوع ModelAndView برگرداند. البته گزینه های دیگری برای مقدار بازگشتی وجود دارد.

اول از همه، ممکن است یک استثنا ایجاد شود. در این مورد، Spring محتوای WebApplicationContext را برای یافتن یک resolver استثنا بررسی می کند. Resolverهای استثنا مولفه هایی هستند که یک استثنا را بازرسی می کنند و ModelAndView مناسب در رابطه با استثناء را برمی گردانند. اگر یکی از resolverها، نتیجه ای از نوع ModelAndView برگرداند، برای ارائه پاسخ به مشتری مورد استفاده قرار خواهد گرفت. به زمانی بیاندیشید که نیاز باشد برای عدم امکان اتصال به پایگاه داده و یا موردی مشابه، هشداری به کاربر داده شود. اگر resolver با مقدار بازگشتی مناسب ModelAndView یافت نشد، استثنای دوباره ای ایجاد خواهد شد، که در این صورت نگاشت استثنای استاندارد که بخشی از فایل web.xml است انتخاب خواهد شد.

دو راه برای مقابله با خطاها در یک برنامه تحت وب وجود دارد. زمانی که خطایی بوجود آید که شما با استفاده از resolverها از آن جلوگیری نکرده باشید، ما به سراغ استفاده از زیرساخت تعیین شده در web.xml می رویم تا اقدامات تعیین شده در آنجا را انجام دهیم. در صورتی که استثنایی از نوع عملکردی پیش آید و یا زمانی که یک استثنا مخصوص Spring رخ دهد، معمولا ما از زیرساخت های استثنای تعیین شده در Spring استفاده می کنیم.

اگر هیچ استثنا رخ ندهد، Spring مقدار ModelAndView بازگردانده شده توسط کنترلر را برای ارائه پاسخ به کاربر استفاده می کند.

همیشه باید پردازش یک درخواست نتیجه ای از نوع ModelAndView داشته باشد. اگر مقداری از نوع ModelAndView بازنگردد، Spring فرض را بر این می گذارد که کنترلر، خود درخواست را پاسخ می دهد و اقدامات بیشتری صورت نمی گیرد. (به این معنی که Spring هیچ view ای را پردازش نمی کند.)

همه inspectorهای موجود در مسیر مجاز به اجرای پس از پردازش درخواست توسط کنترلر هستند؛ درست قبل از اینکه Spring شروع به آماده سازی پاسخ کند و یا بعد از آماده شدن بسته پاسخ. در نهایت، پس از پایان پردازش درخواست، Spring این خبر را به شما می دهد. این کار با استفاده از زیرساخت اطلاع رسانی رویداد موجود در ApplicationContext انجام می شود. رویدادی که  اینجا ایجاد می شود از نوع org.springframework.web.context.support.RequestHandledEvent است.

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

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