Spring سعی در اختراع دوباره چرخ ندارد. این فریم ورک بهترین شیوه ها و راه حل ها را با هم ادغام کرده است؛ مثلا در مورد دسترسی به داده ها می توان به Hibernate و iBatis اشاره کرد. با این حال، Spring بسته MVC خود را فراهم می کند. با توجه به وجود پیاده سازی های محبوب دیگر MVC مانند Struts و WebWork، ممکن است این سوال به وجود آید که چه نیازی به ایجاد یک بسته مجزای MVC است.
منطق پشت پیاده سازی یک MVC دیگر، در این واقعیت نهفته است که پیاده سازی عادی دیگر به اندازه کافی راه حل های ظریفی ارائه نمی دهند. Spring به وضوح مجموعه ای از اهداف را برای بسته بندی در نظر گرفته است:
- یک پیاده سازی MVC باید غیر سرزده[۱] باشد. در صورت امکان، شما نباید مجبور باشید شیوه ها و یا استانداردهای تعیین شده توسط توسعه دهندگان یک فریم ورک MVC را استفاده کنید. به عنوان مثال می توان به نیاز به extend کردن کلاس اختصاصی فریم ورک جهت اتصال پویای پارامترهای درخواست به اشیاء دامنه اشاره کرد. در واقع، شما نباید برای ایجاد یک کنترل برای اجرای منطق خود مجبور به انجام این کار باشید. در نهایت، اعتبار سنجی نباید به front-end بسته شود؛ ممکن است شما ترجیح دهید انجام این کار در قدم بعد، یعنی منطق کسب و کار[۲] صورت پذیرد. Spring در هر جا امکان پذیر باشد از رابط هایی استفاده می کند؛ شما محدود به استفاده از قابلیتی که تنها با فریم ورک ارائه شده، نیستید و به راحتی می توانید از ابزارهایی که خود پیاده سازی کرده اید استفاده کنید.
- در برنامه های کاربردی وبی که در طول زمان توسعه یافته اند، ممکن است تفاوت هایی از لحاظ فن آوری های استفاده شده در view، نیازهای کارایی، و یا روشی که فریم ورک تعیین می کند که کدام کنترلر برای انجام یک درخواست خاص استفاده شود دیده شود. یک فریم ورک MVC باید برای محیط هایی که شرایط مختلف دارند مناسب باشد. برای مثال، باید این امکان وجو داشته باشد که یک کنترلر با عملکرد بالا، تنها برای پیاده سازی نیازهای اساسی پیاده سازی شود و همچنین کنترلری پیاده سازی شود که مراحل یک گردش کار از جمله اعتبار سنجی، پیام خطا دادن، اتصال داده، و تشخیص برای ارسال فرم نامعتبر را اجرا کند.
- یک بسته MVC نباید پیش فرضی نسبت به تکنولوژی مورد استفاده برای view داشته باشد. پیاده سازی کنترلر و یا محتویات یک مدل نباید با جایگزینی JavaServer Page به جای Velocity، و یا حضور هر دو شی نمایش HTML و تولید کننده فایل PDF تغییر کند. همچنین باید این امکان وجود داشته باشد که به راحتی از فن آوری های جدید ارائه شده در زمینه view استفاده کرد.
- باید آزادی کاملی برای تولید کد HTML وجود داشته باشد. فریم ورک تنها باید ابزارهای ساده و کوچکی (همانند کتابخانه ها سفارشی tag) درون خود داشته باشد که قابلیت های ارائه شده در خود را با آنها ارائه دهد.
- یک فریم ورک باید بسیار قابل تنظیم و سازگار با روشی باشد که در طول پیاده سازی استفاده می شود. روشی که خدمات لایه میانی مدیریت و پیکربندی می شوند نباید هیچ تفاوتی با روال راه اندازی کنترلرها، viewها، و هر قابلیت دیگر مربوط به وب داشته باشد. تمام مزایای تزریق وابستگی[۳] باید در لایه وب قابل استفاده باشند.
- بهتر است لایه های MVC با ارائه راه آسان برای ارسال درخواست ها به لایه های میانی و یکپارچه شدن با خدمات دیگر مانند AOP، تا حد ممکن نازک باشند.
تعدادی از این نیازها از تجربه های راد جانسون – معمار برنامه های کاربردی تحت وب از سال ۱۹۹۹ تا ۲۰۰۱ – بدست آمده است. همه این نیازها، به جای نظری بودن، عملی هستند. این نیازها در بسیاری از مواقع و برای بسیاری از کاربران دیده شده اند.
[۱] Non-intrusive
[۲] Business Logic
[۳] Dependency Injection
نیازهای یک فریم ورک وب MVC خوب – Spring MVC
