مقدمه ای بر اسپرینگ – Spring MVC

چارچوب[۱] اسپرینگ یک چارچوب نرم افزاری و یک ظرف[۲] کنترل وارونگی[۳]برای سکوی[۴] جاوا است. ویژگی های اصلی این چارچوب می تواند توسط هر نرم افزار جاوا استفاده شود، اما گسترش هایی[۵] بر روی این چارچوب وجود دارد که برای ساخت برنامه های کاربردی وب بر روی سکوی Java EE به کار می روند. اگرچه این چارچوب، هیچ مدل برنامه نویسی خاصی را تحمیل نمی کند، اما در جامعه جاوا به عنوان یک مدل جایگزین و یا حتی افزونه ای بر مدل تجاری JavaBeans (EJB) تبدیل شده است. این چارچوب اسپرینگ به صورت منبع باز[۶] در دسترس قرار گرفته شده است.

تاریخچه

اولین نسخه اسپرینگ توسط راد جانسون نوشته شد. او این چارچوب را همراه با انتشار کتاب خود به نام Expert One-on-One J2EE Design and Development در اکتبر ۲۰۰۲ منتشر کرد. این چارچوب در ابتدا تحت مجوز آپاچی ۲٫۰ در ماه ژوئن سال ۲۰۰۳ منتشر شد. اولین تغییرات این چارچوب، در ویرایش ۱٫۰ و در ماه مارس سال ۲۰۰۴ منتشر شد. در سپتامبر ۲۰۰۴ و مارس ۲۰۰۵ نسخه های بعدی آن نیز منتشر شدند. نسخه ۱٫۲٫۶ چارچوب اسپرینگ در سال ۲۰۰۶ برنده جایزه های Jolt productivity و JAX Innovation شد. نسخه های ۲٫۰، ۲٫۵، ۳٫۰، ۳٫۱، ۳٫۲٫۵ و ۴ این چارچوب به ترتیب در اکتبر ۲۰۰۶، نوامبر ۲۰۰۷، دسامبر ۲۰۰۹، دسامبر ۲۰۱۱، نوامبر ۲۰۱۳ و دسامبر ۲۰۱۳ منتشر شدند. پیشرفت های قابل توجه نسخه ۴٫۰ این چارچوب شامل پشتیبانی از Java SE8، Groovy 2، برخی از ویژگی های Java EE7 و WebSocket می شود.

چارچوب اسپرینگ نسخه ۴٫۲٫۰ در تاریخ ۳۱ ژوئیه سال ۲۰۱۵ منتشر شد و بلافاصله به نسخه ۴٫۲٫۱ که در اول سپتامبر ۲۰۱۵ منتشر شد، ارتقا یافت. این نسخه با جاوا ۶، ۷ و ۸، با تمرکز بر اصلاحات هسته ای و قابلیت های وب مدرن سازگار است. چارچوب اسپرینگ نسخه ۴٫۳ در ۱۰ ژوئن ۲۰۱۶ منتشر شد. هم اکنون نسخه ۴٫۳٫۰ RC1 در دسترس است.

ماژول ها

چارچوب اسپرینگ شامل چند ماژول مختلف است که طیف وسیعی از خدمات را ارائه می دهند:

  • ظرف هسته اسپرینگ: این ماژول پایه اسپرینگ است و ظروف اسپرینگ (BeanFactory و ApplicationContext) را فراهم می آورد.
  • برنامه نویسی جنبه گرا: این ماژول امکان پیاده سازی زیرسیستم های فرای پروژه[۷] را فراهم می کند.
  • احراز هویت و بررسی مجوز: فرآیندهای امنیتی قابل تنظیم که طیفی وسیعی از استانداردها، پروتکل ها، ابزار و شیوه ها را از طریق زیر پروژه های امنیت اسپرینگ[۸] (قبلا به سیستم های امنیتی Acegi معروف بودند) پشتیبانی می کند.
  • قرارداد بر روی تنظیمات[۹]: یک روش تولید سریع نرم افزار برای توسعه برنامه های سازمانی بر پایه اسپرینگ که در ماژول Spring Roo ارائه شده است.
  • دسترسی به داده ها[۱۰]: کار با سیستم های مدیریت پایگاه داده رابطه ای بر روی سکوی جاوا، با استفاده از JDBC و ابزارهای نگاشت شی-رابطه[۱۱] و سیستم های پایگاه داده NoSQL
  • ظرف وارونگی کنترل[۱۲]: پیکربندی اجزای نرم افزار و مدیریت چرخه عمر اشیاء جاوا، غالبا از طریق تزریق وابستگی[۱۳].
  • اطلاع رسانی[۱۴]: ثبت اشیاء شنونده پیام[۱۵]، به صورت قابل تنظیم، برای دریافت پیام شفاف[۱۶] از صف پیام و از طریق JMS، بهبود ارسال پیام بر روی استاندارد واسط های برنامه نویسی JMS
  • مدل-نمایش-کنترلر[۱۷]: چارچوبی بر پایه HTTP و Servlet که برای توسعه و سفارشی سازی برنامه های کاربردی وب و خدمات وب RESTful به کار می رود.
  • چارچوب دسترسی از راه دور: امکان تبدیل فرمت اشیاء جاوا، به صورت قابل تنظیم و مبتنی بر RPC و بر روی شبکه هایی که از RMI، CORBA و پروتکل های مبتنی بر HTTP، مانند SOAP، حمایت می کنند.
  • مدیریت تراکنش: این ماژول چند واسط برنامه نویسی مدیریت تراکنش را یکپارچه کرده و تراکنش ها را برای اشیاء جاوا هماهنگ می کند.
  • مدیریت از راه دور: این ماژول اشیاء جاوا را برای پیکربندی محلی و یا از راه دور و از طریق JMX، مدیریت می کند. این مدیریت بر اساس نیاز قابل تنظیم است.
  • تست: کلاس های پشتیبانی برای تهیه تست های واحد[۱۸] و یکپارچه[۱۹].

ظرف وارونگی کنترل (تزریق وابستگی)

در مرکز چارچوب اسپرینگ، ظرف وارونگی کنترل (IOC) قرار دارد که ابزار سازگاری را با استفاده از reflection، برای پیکربندی و مدیریت اشیاء جاوا فراهم می کند.این ظرف مسئول مدیریت چرخه حیات اشیاء خاصی است: ایجاد این اشیاء، فراخوانی متدهای مقداردهی اولیه آن ها و پیکربندی این اشیاء توسط اتصال آن ها به یکدیگر.

اشیاءای که توسط این ظرف ایجاد می شوند، به نام اشیاء مدیریت شده و یا bean نامیده می شوند. این ظرف می تواند توسط بارگذاری فایل های XML و یا annotationهای خاص جاوا پیکربندی شود. این ابزارهای تنظیم، حاوی تعاریف bean هستند که اطلاعات مورد نیاز برای ایجاد هر یک از beanها در این ابزارها مشخص شده است.

اشیاء می توانند با استفاده از جستجوی وابستگی و یا تزریق وابستگی به دست آیند. جستجوی وابستگی الگویی است که توسط آن درخواست دهنده از ظرف اشیاء، شی ای را با تعیین نام و یا نوع خاص آن درخواست می کند. تزریق وابستگی الگویی است که در آن ظرف اشیاء، شی ای را که توسط نام مشخص شده است، از طریق سازنده ها، خواص[۲۰]، و یا متدهای کارخانه[۲۱] به شی درخواست دهنده ارسال می کند.

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

این ظرف می تواند با استفاده از پروژه Pitchfork، به یک ظرف تا حدی سازگار با EJB 3.0 تبدیل شود. عده ای از این بابت که چارچوب اسپرینگ با استانداردها انطباق ندارد، از آن انتقاد می کنند. با این حال، SpringSource انطباق با EJB 3 را به عنوان یک هدف اصلی نمی بیند و ادعا می کند که چارچوب اسپرینگ و ظرف وارونگی کنترل اجازه مدل های برنامه نویسی قوی تری را می دهند. شما شی ای ایجاد نمی کنید، اما با تعریف آن شی در فایل پیکربندی اسپرینگ توضیح می دهید که چگونه باید ایجاد شود. شما سرویس و یا مولفه ای را فراخوانی نمی کنید، اما با تعریف آن ها را در فایل های پیکربندی اسپرینگ مشخص می کنید که کدام سرویس و مولفه ای باید فراخوانی شود. این کار نگه داری از کد و تست آن از طریق IoC را ساده تر می کند.

چارچوب برنامه نویسی جنبه گرا

اسپرینگ، چارچوب برنامه نویسی جنبه گرای[۲۲] (AOP) خاص خود را دارد. این چارچوب زیرسیستم های فرای پروژه را در جنبه[۲۳] ها ماژوله می کند. انگیزه ایجاد یک چارچوب AOP جداگانه از آن جا می آید که می توان ویژگی های اساسی AOP را بدون پیچیدگی زیاد در طراحی، اجرا، و یا پیکربندی به وجود آورد. چارچوب AOP اسپرینگ نیز استفاده زیادی از ظرف اسپرینگ می کند.

چارچوب AOP اسپرینگ، مبتنی بر الگوی پراکسی[۲۴] است و در زمان اجرا پیکربندی می شود. این رویکرد، یک گام از کامپایل یا بارگذاری برنامه را حذف می کند. از سوی دیگر، interception فقط اجازه اجرای متدهای عمومی را در اشیاء موجود در یک نقطه الحاق[۲۵] می دهد.

قدرت و پیچیدگی اسپرینگ AOP در مقایسه با چارچوب AspectJ کمتر است. اسپرینگ ۱٫۲ شامل امکانات لازم برای پیکربندی جنبه های AspectJ در ظرف خود است. اسپرینگ ۲٫۰ برای یکپارچه شدن با AspectJ امکانات بیشتری دارد. برای مثال، زبان pointcut، مورد استفاده مجدد قرار گرفته است و می تواند در کنار جنبه مبتنی بر اسپرینگ AOP استفاده شود. علاوه بر این، اسپرینگ ۲٫۰ یک کتابخانه جنبه های اسپرینگ اضافه کرده است که از AspectJ برای ارائه ویژگی های معمول اسپرینگ مانند مدیریت تراکنش اعلانی و تزریق وابستگی از طریق AspectJ در زمان کامپایل و یا بارگذاری در زمان اجرا استفاده می کند. همچنین SpringSource از AspectJ AOP در سایر پروژه های اسپرینگ مانند Spring Roo و Spring Insight استفاده می کند. همچنین Spring Security یک کتابخانه جنبه مبتنی بر AspectJ ارائه داده است.

اسپرینگ AOP به گونه ای طراحی شده است که امکان کار با زیرسیستم های فرای پروژه در داخل چارچوب اسپرینگ را فراهم آورد. هر شی ای که با استفاده از ظرف اسپرینگ ایجاد و پیکربندی شده باشد می تواند توسط اسپرینگ AOP توسعه یابد.

چارچوب اسپرینگ برای مدیریت تراکنش، امنیت، دسترسی از راه دور و JMX، در درون خود از اسپرینگ AOP استفاده می کند.

از نسخه ۲٫۰ به بعد، چارچوب اسپرینگ دو روش برای پیکربندی AOP فراهم می کند:

  • رویکرد مبتنی بر شما[۲۶]
  • Annotationهای مبتنی بر @AspectJ

 

تیم اسپرینگ این گونه تصمیم گرفتند که اصطلاحات جدیدی مبتنی بر AOP تعریف نکنند؛ بنابراین، در اسناد و APIهای مرجع اسپرینگ، واژه هایی مانند جنبه[۲۷]، نقطه الحاق، advice، pointcut، introduction، شی هدف[۲۸] (شی advised)، پروکسی AOP و weaving، دارای معانی مشابه اکثر چارچوب های AOP دیگر (به ویژه AspectJ) را دارند.

چارچوب دسترسی به داده ها

چارچوب دسترسی به داده های اسپرینگ، مسائلی که در هنگام کار با پایگاه های داده در برنامه های کاربردی در بین توسعه دهندگان، مشترک است را عنوان می کند. این چارچوب، تمام چارچوب های دسترسی به داده در جاوا، مانند JDBC، iBatis/MyBatis، Hibernate، JDO، JPA، Oracle TopLink، Apache OJB، و Apache Cayenne را پشتیبانی می کند.

اسپرینگ برای همه چارچوب های پشتیبانی شده، ویژگی های زیر را فراهم می کند:

  • مدیریت منابع – به طور خودکار منابع پایگاه داده را به دست آورده و آزاد می کند
  • پردازش استثنا – استثناهای مربوط به دسترسی به داده های را به یک ساختار سلسله مراتبی دسترسی به داده های اسپرینگ ترجمه می کند
  • مشارکت در تراکنش – مشارکت شفاف در تراکنش های جاری
  • باز کردن منابع – اشیاء پایگاه داده را از wrapperهای استخر ارتباطی[۲۹] بازیابی می کند
  • ایجاد انتزاع برای کنترل کردن BLOB و CLOB

این ویژگی ها، هنگامی در دسترس قرار می گیرند که از کلاس های قالبی که توسط اسپرینگ برای هر چارچوب تهیه شده است، استفاده شود. منتقدان، این کلاس های قالب را ناخوانده دانسته و در آن هیچ مزیتی نسبت به استفاده مستقیم از (برای مثال) Hibernate API ندیده اند. در پاسخ باید گفت که توسعه دهندگان اسپرینگ امکان استفاده مستقیم رابط های برنامه کاربردی Hibernate و JPA را فراهم کرده اند. اما این کار، به مدیریت تراکنش شفاف نیاز دارد، زیرا کد برنامه، دیگر مسئولیت تهیه و بستن منابع پایگاه داده را ندارد و ترجمه استثنا را پشتیبانی نمی کند.

چارچوب دسترسی به داده های اسپرینگ، به همراه مدیریت تراکنش خود، یک انتزاع انعطاف پذیر برای کار با چارچوب دسترسی به داده ها ارائه می دهد. چارچوب اسپرینگ، API عمومی برای دسترسی به داده ها را ارائه نمی دهد، بلکه به جای آن، قدرت کامل رابط های برنامه کاربردی پشتیبانی شده، دست نخورده نگه داشته شده است. چارچوب اسپرینگ تنها چارچوب موجود در جاوا است که مدیریت محیط دسترسی به داده ها را در خارج از یک سرور نرم افزار و یا یک ظرف ارائه می دهد.

در هنگام استفاده از اسپرینگ برای مدیریت تراکنش با Hibernate، نیاز است beanهای زیر تنظیم شوند:

  • یک منبع داده مانند com.mchange.v2.c3p0.ComboPooledDataSource یا org.apache.commons.dbcp.BasicDataSource
  • یک SessionFactory مثل org.springframework.orm.hibernate3.LocalSessionFactoryBean به همراه ویژگی DataSource
  • یک HibernateProperties مانند org.springframework.beans.factory.config.PropertiesFactoryBean
  • یک TransactionManager مانند org.springframework.orm.hibernate3.HibernateTransactionManager  به همراه یک ویژگی SessionFactory

چارچوب مدیریت تراکنش

چارچوب مدیریت تراکنش اسپرینگ، یک مکانیزم انتزاعی را برای سکوی جاوا به ارمغان می آورد. این انتزاع قادر است:

  • با تراکنش های محلی و عمومی (تراکنش محلی به سرور نرم افزار نیاز ندارد) کار کند
  • با تراکنشهای تودرتو کار کند
  • با savepointها[۳۰] کار کند
  • تقریبا در تمام محیط های چارچوب جاوا کار کند

در مقام مقایسه، JTA تنها از تراکنشهای تودرتو و عمومی پشتیبانی می کند و به یک سرور نرم افزار (و در برخی موارد نیز استقرار برنامه های کاربردی در یک سرور نرم افزار) نیاز دارد.

در چارچوب اسپرینگ یک PlatformTransactionManager قرار دارد و شامل تعدادی استراتژی برای مدیریت تراکنش های زیر است:

  • تراکنش هایی که بر روی یک اتصال JDBC مدیریت می شوند
  • تراکنش هایی که بر روی واحدهای کاری[۳۱] نگاشت شی رابطه[۳۲] مدیریت می شوند
  • تراکنش هایی که از طریق JTA TransactionManager و UserTransaction مدیریت می شوند
  • تراکنش هایی که بر روی منابع دیگر، مانند پایگاه داده های شی مدیریت می شوند

این چارچوب علاوه بر ایجاد این انتزاع، دو روش برای افزودن مدیریت تراکنش به برنامه های کاربردی فراهم می کند:

  • از طریق برنامه نویسی، با استفاده از TransactionTemplate موجود در اسپرینگ
  • از طریق تنظیمات، با استفاده از ابرداده ها[۳۳] مانند XML و یا annotationهای جاوا (@Transactional، و غیره)

در کنار چارچوب دسترسی به داده های اسپرینگ – که با چارچوب مدیریت تراکنش یکپارچه شده است – این امکان وجود دارد که یک سیستم تراکنش را از طریق پیکربندی و بدون نیاز به استفاده از JTA و EJB برپا کرد. این چارچوب تراکنش همچنین با موتورهای پیام[۳۴] و کش[۳۵] نیز یکپارچه شده است.

چارچوب مدل نمایش کنترلر

چارچوب اسپرینگ، فریم ورک تحت وب MVC خود را که از ابتدا برنامه ریزی نشده بود، ارائه داده است. توسعه دهندگان اسپرینگ در واکنش به طراحی ضعیفی که در چارچوب محبوب وب Jakarta Struts دیده بودند و همچنین کمبودهایی که در دیگر چارچوب های در دسترس مشاهده کرده بودند، تصمیم به نوشتن چارچوب وب خود گرفتند. به طور خاص، آن ها احساس کردند که فاصله کافی بین لایه های نمایش و کنترل درخواست، و بین لایه های کنترل درخواست و مدل وجود ندارد.

اسپرینگ MVC، مانند Struts، یک چارچوب مبتنی بر درخواست است. این چارچوب رابط های استراتژی[۳۶] را برای تمام مسئولیت هایی که باید توسط یک چارچوب مبتنی بر درخواست مدرن کنترل شود، تعریف می کند. هدف هر رابط این است که به گونه ای ساده باشد که کاربران اسپرینگ MVC، در صورت تمایل بتوانند به راحتی پیاده سازی مورد نظر خود را برای آن داشته باشند. MVC راه را برای کد frontend راحت تر می کند. همه رابط ها به Servlet API متصل می شوند. این اتصال قوی به Servlet API، توسط برخی ها به عنوان یک نقص در ارائه یک انتزاع سطح بالا برای برنامه های کاربردی مبتنی بر وب دیده می شود. با این حال، این اتصال این اطمینان را می دهد که همزمان با تسهیل استفاده از Servlet API، در کنار سطح بالای انتزاع این چارچوب، ویژگی های این API نیز در دسترس توسعه دهندگان باقی می ماند.

کلاس DispatcherServlet، کنترلر جلویی[۳۷] این چارچوب است و مسئول این است که در طول مراحل اجرای یک درخواست HTTP، کنترل را به رابط های مختلف بسپارد.

مهم ترین رابط های تعریف شده توسط اسپرینگ MVC و مسئولیت های هر یک، به شرح زیر است:

  • Controller: برای مدیریت درخواست های ورودی و تغییر مسیر آن به پاسخ مناسب، بین مدل و نمایش قرار می گیرد. این رابط به عنوان یک دروازه برای هدایت اطلاعات ورودی عمل می کند.
  • HandlerAdapter: اجرای اشیاءای را بر عهده دارد که مسئول رسیدگی به درخواست های دریافتی هستند.
  • HandlerInterceptor: مشابه Servlet filter، درخواست های ورودی را intercept می کند، اما با آن برابر نیست (استفاده از آن اختیاری است و توسط DispatcherServlet کنترل نمی شود).
  • HandlerMapping: اشیاءای را که مسئولیت رسیدگی به درخواست های دریافتی دارند، یعنی همان کنترلرها، بر اساس هر یک از ویژگی یا شرایط داخلی و خارجی آن درخواست، انتخاب می کند.
  • LocaleResolver: تعیین و در صورت تمایل ذخیره زبان هر یک از کاربران.
  • MultipartResolver: کار با آپلود فایل را با بسته بندی درخواست های ورودی تسهیل می کند.
  • View: مسئول بازگرداندن پاسخ به مشتری است. ممکن است برخی از درخواست بدون رفتن به بخش مدل، مستقیما به بخش نمایش بروند؛ سایر درخواست ها از هر سه عنصر خواهند گذشت.
  • ViewResolver: یک نمایش را بر اساس نام منطقی آن انتخاب می کند (استفاده از آن اختیاری می باشد).

تمام رابط های استراتژی تعریف شده در بالا، مسئولیت مهمی را در چارچوب کلی بر عهده دارند. انتزاع ارائه شده توسط این رابط ها قدرتمند است، بنابراین برای این که اسپرینگ MVC اجازه مجموعه ای از تغییرات را در پیاده سازی آن ها بدهد، درون خود پیاده سازی همه این رابط را به همراه دارد که در کنار هم، مجموعه ای از ویژگی ها را بر روی Servlet API تعریف می کنند. با این حال، توسعه دهندگان و فروشندگان می توانند پیاده سازی خود را برای آن ها داشته باشند. اسپرینگ MVC از رابط جاوا java.util.Map به عنوان یک انتزاع داده گرا برای مدل استفاده می کند که در این رابط، از رشته به عنوان کلید استفاده می شود.

یکی از مزایای مهمی که از سطح بالای انتزاع ارائه شده توسط اسپرینگ MVC بدست می آید، سهولت تست پیاده سازی این رابط ها است. DispatcherServlet کاملا به ظرف کنترل وارونگی اسپرینگ متصل شده است و به همین دلیل امکان پیکربندی لایه های وب را در برنامه های کاربردی به خوبی فراهم کرده است. با این حال، برنامه های کاربردی وب می توانند بخش های دیگر چارچوب اسپرینگ، از جمله ظرف اسپرینگ را انتخاب کنند و از خود اسپرینگ MVC استفاده نکنند.

چارچوب دسترسی از راه دور

چارچوب دسترسی از راه دور اسپرینگ یک انتزاع مناسب برای کار با فن آوری های مختلف بر پایه RPC ایجاد می کند. این فن آوری ها بر روی سکوی جاوا قرار دارند و هم برای اتصال مشتری و هم هدایت اشیاء بر روی سرور در دسترس هستند. مهم ترین ویژگی ارائه شده توسط این چارچوب این است که می توان این فن آوری ها را تا آنجا که ممکن است با ترکیب کنترل وارونگی و AOP، به راحتی پیکربندی و استفاده کرد.

این چارچوب همچنین بازیابی پس از بروز خطا (پس از قطع ارتباط، به صورت خودکار ارتباط مجدد برقرار می شود) و برخی از بهینه سازی ها برای استفاده سرویس گیرنده از beanهای نشست از راه دور EJB را فراهم می کند.

اسپرینگ پروتکل ها و محصولات زیر را به صورت آماده درون خود دارد:

  • پروتکل های مبتنی بر HTTP
    • Hessian: پروتکل سریال سازی دودویی و منبع باز[۳۸] است و توسط پروتکل های مبتنی بر CORBA نگهداری می شود
    • RMI (1): فراخوانی توابع با استفاده از زیرساخت RMI، مخصوص اسپرینگ
    • RMI (2): فراخوانی توابع با استفاده از رابط های RMI که با استفاده عادی RMI مطابقت دارد
    • RMI-IIOP (CORBA): فراخوانی توابع با استفاده از RMI-IIOP/CORBA
  • یکپارچه سازی مشتری Enterprise JavaBean
    • اتصال bean نشست EJB محلی: اتصال به beanهای نشست محلی
    • اتصال bean نشست EJB راه دور: اتصال به beanهای نشست راه دور
  • SOAP
    • یکپارچه سازی با سرویس های وب چارچوب Apache Axis

Apache CXF امکان یکپارچه سازی با چارچوب اسپرینگ برای مبتنی بر RPC را برای ارسال اشیا از سرور فراهم می کند.

تنظیمات راه اندازی کلاینت و سرور، برای تمام پروتکل ها و محصولات مبتنی بر RPC، که توسط چارچوب اسپرینگ دسترسی از راه دور پشتیبانی می شوند (به جز Apache Axis)، در ظرف هسته اسپرینگ انجام می شود.

رویکرد قرارداد بر روی پیکربندی[۳۹] برای توسعه سریع نرم افزار

Spring Boot

Spring Boot پیاده سازی “قرار داد بر روی پیکربندی” درون اسپرینگ است که برای ایجاد برنامه های کاربردی مستقل و مبتنی بر اسپرینگ به کار می رود و بدون هیچ تغییری، به راحتی اجرا می شود. این امکان، یک نمای خاصی از سکوی اسپرینگ و کتابخانه های شخص ثالث را تحویل می دهد و بنابراین شما می توانید با تغییرات در این ماژول، برنامه را اجرا کنید. اکثر برنامه های کاربردی Spring Boot به میزان کمی به پیکربندی اسپرینگ نیاز دارند. امکانات ارائه شده عبارتند از:

  • برنامه های مستقل کاربردی اسپرینگ ایجاد می کند
  • Tomcat یا Jetty را به طور مستقیم درون برنامه قرار می دهد (بدون نیاز به استقرار فایل های WAR)
  • POMهای راه اندازی تهیه می کند تا پیکربندی Maven ساده تر شود
  • هر زمان که ممکن باشد، به صورت خودکار اسپرینگ را پیکربندی می کند
  • ویژگی های آماده ارائه می دهد، مانند متریک ها، چک سلامتی[۴۰] و پیکربندی بیرونی[۴۱]
  • مطلقا هیچ تولید کد و پیکربندی XML نیاز نیست

Spring Roo

Spring Roo یک رویکرد مبتنی بر تولید کد جایگزین است که برای سرعت بخشیدن به تولید برنامه در جاوا، از رویکرد قرارداد بر روی پیکربندی استفاده می کند. این ابزار در حال حاضر Spring Framework، Spring Security و Spring Web Flow را پشتیبانی می کند. Roo به علل زیر نسبت به سایر چارچوب های توسعه سریع نرم افزار متفاوت است:

  • توسعه پذیری (از طریق افزودنی ها[۴۲])
  • بهره وری سکوی جاوا (بر خلاف سایر زبان ها)
  • Roo می تواند در عرض چند دقیقه از هر برنامه حذف شود
  • قابلیت استفاده (به ویژه از طریق ویژگی های پوسته[۴۳] و الگوهای استفاده)

چارچوب Batch

Spring Batch چارچوبی برای پردازش دسته ای است که توابع قابل استفاده مجدد برای پردازش حجم زیادی از اطلاعات را فراهم می کند، از جمله:

  • ثبت[۴۴]/ردیابی[۴۵]
  • مدیریت تراکنش
  • تهیه اطلاعات آماری مربوط به یک پردازش
  • راه اندازی مجدد یک کار

این کتابخانه همچنین خدمات و ویژگی های فنی پیشرفته تری ارائه می دهد که کارهای دسته ای با حجم و کارایی بسیار بالا بهینه سازی شده و از تکنیک های پارتیشن بندی درون آن ها استفاده شود. Spring Batch یک چارچوب برای پردازش های دسته ای است – دنباله ای از کارها را اجرا می کند. در Spring Batch، یک کار متشکل از تعداد زیادی مرحله است و هر مرحله شامل یک وظیفه READ-PROCESS-WRITE و یا یک واحد کاری (tasklet) می شود.

منظور از اصطلاح READ-PROCESS-WRITE، خواندن داده ها از منابع (CSV، XML و یا پایگاه داده)، پردازش و ذخیره آن در منابع دیگر (CSV، XML و پایگاه داده) است. برای مثال، یک مرحله می تواند داده ها را از یک فایل CSV خوانده، آن ها را پردازش کرده و در پایگاه داده ذخیره کند. Spring Batch کلاس های ساخته شده زیادی را برای خواندن/نوشتن در CSV، XML و پایگاه داده فراهم می کند.

منظور از یک واحد کاری (tasklet) این است که تنها یک وظیفه انجام شود، مثل تمیز کردن منابع بعد و یا قبل این که یک گام آغاز شود و یا پایان پذیرد. مراحل را می توان با هم زنجیر کرد و به عنوان یک کار به اجرا در آورد.

چارچوب Integration

Spring Integration چارچوبی برای یکپارچه سازی نرم افزارهای تجاری فراهم می کند که درون آن توابع قابل استفاده مجدد و ضروری برای پیام رسانی، و یا معماری رویداد محور قرار می گیرد. این معماری شامل بخش های زیر است:

  • مسیریاب[۴۶] – یک پیام را بر اساس شرایط خاص به یک کانال پیام هدایت می کند
  • مبدل[۴۷] – بدنه پیام را تغییر داده و یک پیام جدید با بدنه تغییر داده شده می سازد
  • آداپتور – برای یکپارچه شدن با دیگر فن آوری ها و سیستم ها (HTTP، AMQP، JMS، XMPP، SMTP، IMAP، FTP (و همچنین FTPS/SFTP)، فایل سیستم، و غیره) به کار می رود
  • فیلتر – پیام را بر اساس معیارهای مشخصی فیلتر می کند. اگر معیارها برآورده نشوند، پیام نادیده گرفته می شود
  • فعال ساز خدمات – یک عملیات را بر روی یک شی خدمات فراخوانی می کند
  • مدیریت و حسابرسی

Spring Integration از معماری های مبتنی بر pipe-and-filter پشتیبانی می کند.

انتقادات

در راستای استفاده بیش از حد چارچوب اسپرینگ از XML انتقاداتی به وجود آمده است. هرچند، از نسخه ۳٫۰٫۰ به بعد، توسعه دهندگان قادر هستند تمام یا بخشی از یک زمینه برنامه را، از طریق annotation تعریف کنند. Spring Boot، برای به حداقل رساندن مقدار پیکربندی که باید نوشته شود، از این امکان استفاده زیادی می کند. علاوه بر این، Spring Tool Suite (STS)، که بر روی Eclipse نصب می شود، در هنگام ویرایش فایل های XML پیکربندی اسپرینگ، امکانات تکمیل کد[۴۸]، اعتبار سنجی[۴۹]، اطلاعات متنی[۵۰] و تصویر گرافیکی[۵۱] را تهیه می کند.

[۱] Framework

[۲] Container

[۳] Inversion Control

[۴] Platform

[۵] Extensions

[۶] Open Source

[۷] Cross-cutting Concerns

[۸] Spring Security

[۹] Convention over Configuration

[۱۰] Data Access

[۱۱] Object-Relational Mapping Tools

[۱۲] Inversion of Control (IoC)

[۱۳] Dependency Injection

[۱۴] Messaging

[۱۵] Message Listener Objects

[۱۶] Transparent Message Consumption

[۱۷] Model-View-Controller

[۱۸] Unit Tests

[۱۹] Integration Tests

[۲۰] Properties

[۲۱] Factory Methods

[۲۲] Aspect Oriented Programming

[۲۳] Concern

[۲۴] Proxy pattern based

[۲۵] Join Point

[۲۶] Schema-based approach

[۲۷] Aspect

[۲۸] Target Object

[۲۹] Connection Pool

[۳۰] امکانی برای پیاده سازی بخش های مجزای یک تراکنش

[۳۱] Units of Work

[۳۲] Object-Relational Mapping

[۳۳] Metadata

[۳۴] Messaging Engines

[۳۵] Cache Engines

[۳۶] Strategy Interface

[۳۷] Front Controller

[۳۸] Open Source

[۳۹] Convention over Configuration Approach

[۴۰] Health Check

[۴۱] Externalized Configuration

[۴۲] Add-Ons

[۴۳] Shell Features

[۴۴] Logging

[۴۵] Tracing

[۴۶] Router

[۴۷] Transformer

[۴۸] Code-Completion

[۴۹] Validation

[۵۰] Contextual Information

[۵۱] Graphical Visualization

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

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