دوره آموزشی Spring Framework & Spring Boot

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

مهم‌ترین عناوینی که در این جلسه مطرح می‌شوند به طور خلاصه عبارت‌اند از:

۱.تاریخچه و کاربرد Spring
۲.معماری Spring
۳.معرفی مفاهیم Bean و Container و پیکربندی Spring
۴.پیاده سازی یک مثال ساده و توضیح اجزا و ارتباطات آن

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

Spring چگونه تولید نرم‌افزار را تسهیل می‌کند؟

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

معماری چندلایه:

هر نرم افزاری که تولید می‌شود از کلاس‌ها و آبجکت‌های مختلفی تشکیل شده است که در مجموع و در تعامل با یکدیگر، کارکرد آن نرم‌افزار را شکل می‌دهند. در یک نرم افزار Enterprise که سرویس‌ها متنوع و کاربران هم زیاد هستند، ممکن است تعداد این کلاس‌ها خیلی زیاد (مثلا چندین هزار) باشد. در نتیجه اگر دیاگرام کلاس که ارتباط بین کلاس‌ها و آبجکت‌های یک برنامه را نشان می‌دهد ترسیم کنیم با گرافی در هم پیچیده از آبجکت‌ها مواجه می‌شویم. اینکه هرکلاسی بتواند هرکلاس دیگری را فراخوانی کند مثل یک شهر بی‌دروپیکر می‌ماند که هرکسی هرکاری دوست داشته باشد انجام می‌دهد! تست کارکرد چنین نرم افزاری بسیار سخت خواهد بود و نگهداری آن سخت‌تر. اگر برای رفع یک اشکال در برنامه مجبور به تغییر یک کلاس شویم چه کلاس‌هایی از برنامه ممکن است تاثیر‌پذیرند و باید نگران کارکرد صحیح چه کلاس‌های از برنامه باشیم؟ قطعا جوابی برای این سوال وجود ندارد زیرا در یک معماری بدون چهارچوب، همه کلاس‌های برنامه بالقوه یا بالفعل ممکن است با کلاس تغییر یافته در ارتباط باشند.

با چنین پیش زمینه‌ای معماری چندلایه تلاش دارد تا اولا کلاس‌های برنامه را در گروه‌های مختلف سازمان‌دهی کند، ثانیا هرگروه را مثل یک لایه روی گروه دیگر قرار دهد و ثالثا ارتباط بین این گروه‌ها (لایه‌ها) را محدود به قبلی و بعدی خودشان کند. به عنوان مثال کلاس‌ها و آبجکت‌هایی که کار ساخت واسط کاربری و تعامل با کاربر را به عهده دارند را می‌توان در یک لایه با نام «لایه View» جای داد، کلاس‌هایی که کارشان پردازش داده، تولید نتایج و انجام تراکنش است در «لایه Business» قرار می‌گیرند و کلاس‌ها و اشیایی که کار ذخیره و بازیابی داده‌ها در دیتابیس به عهده دارند در یک لایه دیگر با نام «لایه Data» قرار داد. کلاس‌ها و اشیایی که کار تولید گزارشات را برعهده دارند در یک لایه دیگر، معماری چندلایه امکان می‌دهد تا لایه‌های یک برنامه در حداکثر استقلال از یکدیگر قابل توسعه و پیاده سازی باشند.

در مورد معماری چندلایه، یک موضوع اهمیت زیادی دارد، ارتباط هر لایه فقط با لایه‌های قبلی و بعدی خودش است و ثانیا این ارتباط یک‌طرفه است. به عنوان مثال لایه View که حاوی کلاس‌ها و اشیای واسط کاربری است فقط با کلاس‌های لایه میانی Business تعامل دارد. کلاس‌های واسط کاربری می‌توانند برای انجام کارکرد خود کلاس‌های لایه میانی را فراخوانی کنند اما نمی‌توانند مستقیما با لایه داده (ذخیره و بازیابی داده) ارتباط داشته باشند. در عین حال ارتباط لایه واسط کاربری با لایه میانی یک ارتباط یک طرفه است. معنی آن این است که کلاس‌های لایه میانی نمی‌توانند و نباید کلاس‌های واسط کاربری را فراخوانی کنند. این قواعد در مورد کلاس‌های لایه میانی و لایه داده نیز صادق است.

مهم‌ترین عناوینی که در جلسه دوم بحث می‌شوند عبارت‌اند از:

۱.تعریف Bean
۲.محدوده حیات Beanها
۳.وابستگی Beanها
۴.تزریق مقادیر ساده (primitives)
۵.استفاده از علامت‌های Required , @Autowired , @Primary , @Resource , @PostConstruct , @PreDestroy@
۶.علامت‌های Inject , @Named@
۷.تنظیم و پیکربندی آبجکت‌ها با استفاده از Bean , @Configuration , @Import@
۸.Beanهای مبتنی بر پروفایل
۹.کار با رخدادهای ApplicationContext (ایجاد و خاتمه)
۱۰.آبجکت‌های Bean Factory و Resource

در جلسه دوم به مهم‌ترین و اصلی‌ترین قابلیت Spring یعنی IOC خواهیم پرداخت. گفته می‌شود که IOC در هسته Spring قرار دارد، این بدین معنی است که برای استفاده از IOC به هیچ کتابخانه خارجی نیاز نیست و اساسا هر پروژه‌ای که مبتنی بر Spring باشد از قابلیت IOC بهره می‌برد. وقتی یک پروژه مبتنی بر Spring را پیاده سازی می‌کنیم، دیگر آبجکت‌های برنامه را با استفاده از New ایجاد نمی‌کنیم. بلکه ایجاد آن‌ها را به عهده Spring می‌گذاریم. به عبارت دیگر در پروژه Spring آبجکت‌های برنامه را ما ایجاد نمی‌کنیم بلکه برنامه ما با فرض اینکه آبجکت‌ها ایجاد شده‌اند صرفا (با فراخوانی متدها و فیلدهای آن‌ها) از آن‌ها استفاده می‌کند. به این آبجکت‌ها که Spring آن‌ها را ایجاد می‌کند Bean گفته می‌شود.

در این جلسه با نحوه تعریف Bean و استفاده از آن‌ها در منطق برنامه آشنا می‌شوید. در این میان با مفاهیم دیگری نیز که مرتبط با تعریف و استفاده از Beanها می‌شوند نیز آشنا می‌شوید. به عنوان نمونه باید بگویم که Beanها چرخه حیات دارند یعنی در یک زمانی توسط Spring ایجاد می‌شوند ما در طول اجرای برنامه از آن‌ها استفاده می‌کنیم و در یک زمانی از بین می‌روند. Spring مسئول مدیریت این چرخه حیات است و در عین حال به ما امکان می‌دهد تا منطق ایجاد (Construction) و ازبین رفتن (Destroy) آن‌ها را شخصی سازی کنیم.

در ادامه این جلسه با مفاهیم پیشرفته‌تری در رابطه با Beanها آشنا می‌شوید. مثلا اگر یک Bean از Bean دیگری استفاده کند نحوه پیکربندی چگونه خواهد بود. همچنین با مفاهیم پیشرفته Spring در رابطه با Beanها آشنا می‌شوید. مثلا اینکه چطور می‌توان یک Bean را از Spring واکشی کرد یا اینکه چطور می‌توان یک Bean Factory را پیاده سازی و به Spring معرفی نمود. Bean Factory در واقع یک Bean است که کار آن تولید Beanهای دیگر است که این جلسه با نحوه پیاده سازی و پیکربندی آن آشنا می‌شوید.

مهم‌ترین موضوعاتی که در این جلسه ارائه می‌شوند عبارت‌اند از:

۱.مفاهیم و اجزای AOP
۲.معرفی آبجکت‌های Target، Advice، Advisor، Proxy و Interceptor
۳.عبارت‌ها و انتخاب کننده‌های Pointcut
۴.آشنایی با صفت‌های Before، After Returning، After Throwing، After) finally) و Around
۵.پشتیبانی از Aspectj

روش شی‌گرایی که امروزه در طراحی و پیاده‌سازی اغلب نرم افزارها استفاده می‌شود کامل‌ترین و پذیرفته‌ترین روش مدل کردن دنیای واقعی است. این روش، با ارائه مفاهیمی از قبیل کلاس، شی، ارث‌بری، متد و فیلد امکان مدل‌سازی دنیای واقعی را فراهم می‌کند اما فاقد مفهومی تحت عنوان «صفت» است. برای درک این نقصان به یک مثال ساده توجه کنید. کلاسی را تصور کنید که دارای یک متد است، حال به نیازمندی‌های زیر توجه کنید:

۱.این متد باید به گونه‌ای باشد که فراخوانی آن فقط در زمان‌های خاصی امکان‌پذیر باشد
۲.با هر فراخوانی این متد یک لاگ در سیستم تولید شود
۳.فقط کاربران خاصی امکان فراخوانی این متد را داشته باشند

با قابلیت‌هایی که از شی‌گرایی در جاوا می‌شناسیم آیا می‌توان بدون تغییر در کدهای این متد نیازمندی‌های فوق را پیاده سازی کرد؟ جواب این سوال منفی است زیرا در شی‌گرایی اگر قرار باشد با فراخوانی یک متد یک عملی دیگر نیز انجام شود، چاره‌ای جز اضافه کردن آن عمل به آن متد وجود ندارد.  مثلا برای اینکه فراخوانی یک متد فقط در زمان‌های خاصی امکان‌پذیر باشد باید با تغییر آن متد کدهایی به ابتدای آن اضافه شود که زمان اجرای متد را کنترل و مانع اجرای آن خارج از برنامه زمانی شود. یا برای اینکه فراخوانی آن متد فقط توسط کاربران خاصی امکان‌پذیر باشد باید کدهایی به ابتدای آن متد اضافه کنیم که با کنترل کاربری که متد را فراخوانی کرده مانع از کارکرد آن متد توسط کاربران غیرمجاز شود. به صورت مشابه برای تولید لاگ باید کدهایی به متد اضافه شود تا در زمان فراخوانی آن متد لاگ تولید نماید.

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

۱.اولین مشکلی که با آن مواجه می‌شویم مشکل تست است. واضح است که تست کردن عملکرد یک متد که در آن دو منطق مجزا با یکدیگر ترکیب شده اند بسیار دشوار خواهد بود.
۲.دومین مسئله‌ای که با آن مواجه خواهیم شد موضوع نگهداری است. اگر در آینده بخواهیم مفهوم اضافه شده به منطق اصلی متد را حذف، غیرفعال یا تغییر دهیم باید آن متد را دست‌کاری کنیم، که اینکار می‌تواند باعث تاثیر ناخواسته در عملکرد اصلی آن متد و این تولید باگ شود.
۳.سومین مشکلی که در این روش پیاده سازی با آن مواجه هستیم این است که اگر به یک مفهوم یکسان (مثلا تولید لاگ در هنگام فراخوانی) در متدهای مختلفی نیاز داشته باشیم. مجبوریم تمام آن متدها را تغییر دهیم و آن مفهوم را به همه آن‌ها اضافه کنیم که این باعث ایجاد کدهای تکراری در برنامه خواهد شد که مشکل تست و نگهداری آن مثل روز برهمگان روشن است!

هدف Aspect Oriented Programming که به آن به اختصار AOP یا «برنامه نویسی مبتنی بر صفت» گفته می‌شود حل مسئله فوق است.

مهم‌ترین عناوینی که در این جلسه ارائه می‌شوند عبارت‌اند از:

۱.نگاشت شی‌گرایی به رابطه‌ای (Object Relational Mapping)
۲.تنظیم و پیکربندی Hibernate
۳.نگاشت آبجکت‌های جاوا به جداول دیتابیس
۴.نگاشت ارث‌بری (Inheritance)
۵.نگاشت وابستگی (Association)
۶.مقایسه Lazy و Eager
۷.کوئری روی دیتابیس با استفاده از HQL و Criteria

تقریبا با قطعیت می‌توان گفت تمام برنامه‌های اینترپرایز از پایگاه داده استفاده می‌کنند. پایگاه داده‌ها خود برنامه‌هایی هستند که کار ذخیره‌سازی و بازیابی داده‌ها را بر عهده دارند و انواع و اقسامی دارند که معروف‌ترین آن‌ها دیتابیس‌های رابطه‌ای (Relational Databases) و دیتابیس‌های غیررابطه‌ای (NoSQL Databases) هستند.

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

از نسخه‌های اولیه جاوا  JDBC API برای پشتیبانی از دیتابیس‌های رابطه‌ای ارائه شده است. اما استفاده از JDBC برای ذخیره و بازیابی دیتا کار پر زحمت و پرهزینه‌ای است زیرا لازم است کدهای SQL را (که منطق و ساختار متفاوتی از برنامه جاوا دارند و توسط کامپایلر جاوا قابل درک نیستند) درون کدهای جاوا کدنویسی کنیم. هر تغییری روی جداول دیتابیس، روی جملات SQL که لابلای کدهای برنامه نوشته شده‌اند تاثیر می‌گذارد، که این موضوع کار تولید، تست و نگهداری برنامه‌های جاوایی را دشوار می‌کند.

به همین دلیل از مدت‌ها قبل، فریم ورک‌ها و کتابخانه‌های واسطه‌ای تحت عنوان ORM معرفی شده‌اند که ما را از نوشتن کدهای SQL لابلای کدهای جاوا مبرا می‌کنند و کار ما را به عنوان تولید کننده نرم افزار به میزان بسیار زیادی آسان می‌کنند. Hibernate یکی از این فریم ورک‌های محبوب و جذاب است.

در این جلسه با نگاهی با تاریخچه Hibernate معماری این فریم‌ورک را بررسی می‌کنیم. نحوه پیکربندی و استفاده از آن را با یک برنامه ساده ملاحظه خواهیم کرد و در ادامه جزییات نگاشت کلاس‌های برنامه (Entity) به جداول دیتابیس (Table) را بحث می‌کنیم. موضوعات دیگری از قبیل نحوه نگاشت ارتباط بین آبجکت‌ها (Association) و ارث‌بری (Inheritance)، نوشتن کوئری مبتنی بر آبجت (HQL و Criteria) از مباحث دیگر این جلسه هستند.

مهم‌ترین موضوعاتی که در این جلسه ارائه می‌شوند عبارت‌اند از:

۱.معرفی آبجکت‌های Repository
۲.فعالسازی Repositoryها
۳.مدیریت تراکنش
۴.زبان کوئری نویسی
۵.استفاده از کوئری‌های پارامتریک
۶.Projection
۷.Locking

اگرچه استفاده از Hibernate کار با دیتابیس‌ها را تا حد زیادی آسان می‌کند اما استفاده از Hibernate آنقدرها هم بی‌دردسر نیست. Spring Data که یکی دیگر از پروژه‌های اکوسیستم Spring است. با ارایه یک لایه روی Hibernate تلاش کرده است تا حد امکان از مشکلات و مسایل کار با Hibernate بکاهد. Spring Data اولا با ارایه یک API غنی، پیاده سازی کلاس‌های لایه دیتا را بسیار ساده می‌کند و نیاز به کوئری نویسی را (به جز موارد خاص) از بین می‌برد. ثانیا مدیریت تراکنش را (که در Hibernate کار پرزحمتی است) را با استفاده از Spring AOP تسهیل می‌کند.

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

مهم‌ترین موضوعاتی که در این جلسه ارائه می‌شوند عبارت‌اند از:

۱.معماری RESTful
۲.پیاده سازی سرویس‌های RESTful در Spring
۳.مدیریت خطاها
۴.مستندسازی سرویس‌های RESTful
۵.مدیریت نسخه‌ها (Versioning)، مرتب سازی (Sorting)، و صفحه بندی (Paging)

تکنولوژی وب، تکنولوژی است که برای ارتباط بین مرورگر وب و وب-سرور استفاده می‌شود و براساس پروتکل‌های رایجی از قبیل HTTP و HTTPS کار می‌کند. در این پروتکل‌ها، داده‌های متنی که عموما هم HTML هستند بین مرورگر وب و وب-سرور ارسال و دریافت می‌شوند. نکته ای که در تکنولوژی وب نهفته است این است که مرورگر وب و وب-سرور هر کدام ممکن است به هر زبانی نوشته شده باشد و روی هر پلتفرمی (Windows، Linux، Solaris، …) اجرا شود، اما از آنجایی‌ که با پروتکل‌های شناخته شده‌ای کار می‌کنند که مستقل از هر پلتفرم و زبانی هسنتد و فرمت داده‌های آن‌ها نیز متن است که آن هم مستقل از هر زبان و هر پلتفرمی است آن‌ها می‌توانند با هم ارتباط داشته باشند. بر همین مبنا یک تکنولوژی جدید معرفی شده است که به آن وب-سرویس گفته می‌شود که مبتنی برتکنولوژی وب است و امکان می‌دهد تا نرم افزارها با استفاده از پروتکل‌های وب (HTTP و HTTPS) و با ارسال و دریافت متن (XML، JSON یا متن ساده) با یکدیگر یکپارچه شوند.

تکنولوژی وب-سرویس در دو نوع اصلی SOAP و REST معرفی شده است، نوع SOAP که قدیمی تر است مبتنی بر XML است اما به علت سرباری که دارد (حجم زیادی دارد و ترافیک زیادی از شبکه را اشغال می‌کند، تولید و پردازش آن پرهزینه است، امکان Cache کردن و Scale کردن آن وجود ندارد) به مرور به حاشیه رفته و نوع REST دقیقا به همان دلایلی که نوع SOAP از آن بی‌بهره است پرطرفدار شده است.

وب-سرویس نوع REST به مرور زمان و با ارایه معماری میکروسرویس بسیار پرطرفدار شده است. در معماری میکروسرویس، اجزای برنامه به سرویس‌های مستقل و جزیی تجزیه می‌شوند که همگی با استفاده از سرویس‌های REST با یکدیگر تعامل دارند.

مهم‌ترین موضوعاتی که در این جلسه بحث می‌شوند عبارت‌اند از:

۱.پیکربندی و تنظیمات
۲.استفاده از دیتابیس
۳.استفاده از JDBC، JPA (Hibernate) برای شناسایی کاربران
۴.استفاده از Encoderها
۵.فعالسازی HTTPS
۶.استفاده از تگ‌های Spring Security

Spring Security یکی از پروژه‌های اکوسیستم Spring است که با بهره‌گیری از سرویس‌هایی که Spring فراهم می‌کند (از قبیل IOC و AOP) بستری را برای توسعه نیازمندی‌های امنیتی یک پروژه جاوایی فراهم می‌کند. واضح است که اصلی‌ترین نیازمندی امنیتی هر سیستم نرم‌افزاری «شناسایی کاربران» (Authentication) و «کنترل دسترسی کاربران» (Authorization) است. یک کاربر می‌تواند یک کاربر انسانی باشد که کار با نرم افزار را دارد یا ممکن است یک نرم افزار یا سیستم دیگر باشد که با سیستم ما در تعامل است. بنابراین ما از زیرساخت امنیت، انتظار داریم تا با نام کاربری و رمز عبوری که وارد می‌کنند آن‌ها را تایید یا رد کند. همچنین وقتی یک کاربری تایید شد از زیرساخت امنیت سیستم انتظار داریم تا دسترسی وی به منابع سیستم را کنترل کند. به عبارت دیگر کنترل کند که آیا کاربر تایید شده حق دسترسی به یک منبع درخواست کرده را دارد یا ندارد. علاوه بر این‌ها ممکن است بخواهیم نرم افزارمان را از طریق یکپارچه سازی با سیستم‌های دیگر از قبیل LDAP، OpenID یا JAAS امن کنیم. به تمام این نیازمندی‌ها باید مقاومت در برای نفوذپذیری‌های رایج از قبیل CSRF یا Session Hijacking را نیز اضافه کنیم. این‌ها سرویس‌های متنوع و جامعی هستند که توسط Spring Security فراهم می‌شوند.

از مدت‌ها قبل از Spring Security، پلتفرم جاوا بسیاری از خدمات فوق را فراهم می‌کرد و می‌کند اما چرا با وجود اینکه جاوا سرویس امنیت را به شکل استاندارد و جهانی فراهم می‌کند، Spring Security متولد شد و هر روز پرطرفدارتر می‌شود؟ شاید ریشه اصلی محبوبیت Spring Security به محبوبیت Spring برگردد. با فراگیرشدن و محبوبیت فراگیر استفاده Spring، تمام محصولاتی که معماری مبتنی بر Spring داشته‌اند نیز شهرت و طرفدار پیدا کرده‌اند. اما در عین حال نباید قابلیت‌های بی نظیر و انعطاف پذیری فراوان Spring Security را از قلم انداخت. Spring Security با فراهم کردن طیف وسیعی از سرویس‌ها و قابلیت‌ها، تمام نیازمندی‌های امنیتی یک پروژه جاوایی را پوشش می‌دهد. پیکربندی و تنظیمات Spring Security می‌تواند کاملا به صورت تعریفی (استفاده از فایل XML) انجام شود که نگهداری آن ‌را بسیار ساده می‌کند. بسیاری از خصوصیات Spring Security قابل توسعه است و بنابراین بسته به نیازمندی‌های امنیتی خاص یک پروژه امکان تغییر و بومی سازی اجزای آن وجود دارد. قابلیت حمل دارد یعنی وقتی در یک پروژه تنظیم و پیکربندی شد بدون توجه به محیط اجرایی و بدون نیاز به پیکربندی محیط اجرایی همراه با پروژه منتقل می‌شود. همچنین باید گفت بسیاری از قابلیت‌هایی که Spring Security فراهم می‌کند در پلتفرم Java EE وجود ندارد و تا اضافه شدن به این پلتفرم ممکن است زمان زیادی بگذرد. این‌ها دلایل کافی هستند که ما Spring Security را به عنوان بستر و زیربنای امنیتی پروژه‌مان انتخاب کنیم.

مهم‌ترین موضوعاتی که در این جلسه در مورد آن‌ها صحبت می‌شوند عبارت‌اند از:

۱.مفاهیم و کاربرد تست
۲.معرفی فریم ورک JUnit و نحوه استفاده از آن
۳.پیاده سازی تست‌های یکپارچگی (Integration) و جزء (Unit)
۴.معرفی فریم ورک Mockito

در طول تولید یک نرم افزار، انواع مختلفی از تست‌ها انجام می‌شود، تست عملکرد و تست کیفیت از جمله این تست‌ها هستند، اما آنچکه موضوع این جلسه است  Unit Test و Integration Test هستند. منظور از Unit، کوچکترین جزء یک برنامه است و  Unit Test به تستی گفته می‌شود که روی کوچکترین قسمت از یک برنامه یعنی متد انجام می‌شود. و منظور از Integration Test (یکپارچگی) تستی است که یکپارچگی اجزای برنامه را تایید می‌کند.

برای این دو نوع تست، کدنویسی می‌شود، یعنی برنامه نویسان همچنان که منطق برنامه را پیاده سازی می‌کنند، کدهایی برای تست جزء و تست یکپارچگی نیز پیاده سازی می‌کنند. دلیل آن هم این است که اولا این دو نوع تست ذاتاً مرتبط با کدهای برنامه و منطق برنامه هستند، ثانیا، با وجود کدهای تست، می‌توان به تست اتوماتیک رسید زیرا با هربار Build برنامه به صورت اتوماتیک اجرا می‌شوند.

برای پیاده سازی Unit Test دو فریم ورک محبوب JUnit و TestNG در جاوا وجود دارند. تنوع فریم ورک‌ها برای پیاده سازی تست‌های یکپارچگی بسیار بیشتر است که یکی از محبوب‌ترین آن‌ها Mockito است که در این جلسه به آن خواهیم پرداخت.

برای تست پروژه‌های مبتنی بر Spring، علاوه بر داشتن دانش تست و مهارت کار با فریم ورک‌های تست، لازم است معماری Spring را خوب درک کرده باشید و نحوه تعامل اجزای یک پروژه Spring را بدانید. با همه این‌ها بازهم تست پروژه‌های Spring‌ای پیچیدگی‌ها و مسائل خودشان را دارند، به همین دلیل Spring تلاش کرده است تا با ارایه فریم ورک تست، پیاده سازی تست در پروژه‌های Spring‌ای را تا حد امکان ساده کند. در این جلسه علاوه بر آشنایی با مفاهیم تست جز و یکپارچگی با فریم ورک‌های تست JUnit و Mockito آشنا می‌شوید و در انتها نحوه تست پروژه‌های مبتنی بر Spring را خواهید آموخت.

مهم‌ترین موضوعاتی که در این جلسه بحث می‌شوند عبارت‌اند از:

۱.پردازش دسته‌ای چیست؟
۲.معرفی اجزای اصلی پردازش دسته‌ای (Reader، Processor و Writer)
۳.معرفی مفاهیم و بازیگران پردازش دسته‌ای
۴.تنظیم، پیکربندی و اجرای فرایند دسته‌ای
۵.زمانبندی اجرای پردازش دسته‌ای

تصور کنید که در یک برنامه حجم زیادی از داده وجود دارد که لازم است یک یا ترکیبی از عملیات زیر روی آن‌ها انجام شود:

• پردازش شود. مثلا روی آن‌ها محاسبات انجام شود و داده‌های دیگری محاسبه شود. مثلا اسناد حسابداری یک شرکت را تصور کنید که در پایان سال برای محاسبه سود و زیان شرکت باید پردازش شوند.
• به داده دیگری تبدیل شود. مثلا داده‌های هواشناسی جمع آوری شده از یک واحد سنجش به واحد سنجش دیگری تبدیل شوند.
• از دیتابیس خارج شود. مثلا داده‌های موجود در یک دیتابیس را برای انتقال به یک محل دیگر، به فایل‌های دیگر منتقل کنیم.
• به دیتابیس وارد شود. مثلا داده‌های موجود در فایل‌های متنی، در یک دیتابیس ذخیره شوند.

در تمام این موارد حجم زیادی از داده وجود دارد که لازم است بدون دخالت کاربر و به صورت خودکار پردازش شوند. در این موارد ممکن است پردازش پیچیده (شامل محاسبات فراوان) یا ساده (فرمت داده، validation، …) باشد یا حتی پردازشی وجود نداشته باشد و صرفا انتقال داده وجود داشته باشد. در همه موارد چه اینکه پردازش وجود داشته باشد یا نباشد با حجم زیادی از داده مواجه هستیم که چالش‌ها و مسایل مختلفی را بوجود می‌آورد. به نمونه چالش‌های زیر توجه کنید:

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

آیا می‌توان عملیات را متوقف کرد و ادامه آن ‌را به زمان دیگری موکول کرد؟

معلوم است که می‌توان برنامه‌ای نوشت که از ابتدا چنین نیازمندی‌هایی را لحاظ کند ولی در این صورت قطعا چرخ را از ابتدا ساخته‌اید زیرا قبلا این چرخ ساخته شده است. Spring Batch یک فریم ورک جاوایی و مبتنی بر Spring است که کار پیاده سازی چنین نیازمندی‌هایی را حتی الامکان ساده و آسان کرده است. البته به جز Spring Batch فریم ورک‌های دیگری نیز وجود دارند و حتی مشخصه JSR-352 در Java EE به همین منظور طراحی شده است که به معنی این است که Application Serverهایی که Java EE7 را پشتیبانی می‌کنند پردازش دسته‌ای را نیز پشتیبانی می‌کنند، اما استفاده از Spring Batch مزایایی دارد که در فریم ورک‌های دیگر و حتی در Java EE7 وجود ندارد.

Spring Batch مبتنی بر Spring است بنابراین می‌توان از سرویس‌های دیگر Spring از قبیل IOC و AOP در پیاده سازی یک «عملیات» استفاده نمود. Spring Batch مبتنی بر POJO است بنابراین کلاس‌هایی که در یک عملیات پیاده سازی می‌شوند در ساده ترین شکل ممکن پیاده سازی می‌شوند.

Spring Batch همچنین مجموعه ای از کلاس‌های عمومی و کاربردی را در اختیار می‌گذارد تا بتوان حتی الامکان با حداقل کدنویسی پردازش دسته‌ای مورد نظر را پیاده سازی نمود. از قابلیت‌های دیگر Spring Batch که در آن تعبیه شده می توان به مدیریت تراکنش، تولید داده‌های آماری در حین عملیات، مدیریت منابع، Loggin/Tracking، Restart و Skip اشاره کرد. Spring Batch همچنین می‌تواند با بخش‌بندی داده‌ها، پردازش داده‌ها را به صورت موازی انجام دهد و به این ترتیب باعث افزایش سرعت و کارایی برنامه شود.

مهم‌ترین موضوعاتی که در این جلسه ارائه می‌شوند عبارت‌اند از:

۱.Spring Boot چیست
۲.معرفی Starterها
۳.پیکربندی و اجرای پروژه Spring Boot
۴.الصاق تنظیمات برنامه و آبجکت‌های برنامه
۵.تعریف تنظیمات برنامه در فایل‌های Properties و Yaml
۶.پروفایل در Spring Boot
۷.مانیتورینگ برنامه Spring Boot با استفاده از Actuator
۸.تولید لاگ
۹.تست

همانطور که در جلسه اول مطرح شد، Spring یک فریم ورک همه منظوره است که طیف وسیعی از ویژگی‌ها و قابلیت‌ها را داراست. همین موضوع باعث شده که پروژه‌های مبتنی بر Spring پیچیده و پیکربندی آن دشوار باشد. به همین دلیل پروژه Spring Boot ابداع شده است تا با ارایه تنظیمات پیش فرض، که به آن Convention over Configuration گفته می‌شود کار تنظیم و راه اندازی پروژه‌های مبتنی بر Spring را تا حد زیادی آسان و ساده کند.

بسته به اینکه از کدامیک از سرویس‌های Spring قصد استفاده داشته باشید، در Spring Boot یک starter ارائه شده است که وابستگی‌ها (dependency) و تنظیمات پیش فرض مربوط به آن سرویس را شامل می‌شود. بنابراین صرفا با افزودن یک starter می‌توان یک سرویس Spring (مثلا ارتباط با دیتابیس، تولید سرویس REST، Spring Security) را به پروژه اضافه کرد.

در این جلسه، مفهوم Profile را خواهید آموخت که نقش کلیدی در پیاده سازی پروژه‌های Spring Boot دارد و امکان می‌دهد یک پروژه را برای محیط‌های مختلف (محیط توسعه، تست، عملیاتی، استیجینگ) تنظیم و پیکربندی کرد.

در ادامه این جلسه نحوه مانیتورینگ سلامت پروژه (Actuator) را خواهید آموخت. واضح است وقتی پروژه‌ای در محیط عملیاتی قرار می‌گیرد، پیگیری وضعیت اجرای برنامه و سلامت سرویس‌های برنامه بسیار حیاتی است، به عنوان نمونه وقتی یک سرویس به دلایل نامشخصی خطا تولید می‌کند لازم است قبل از آنکه مشتری آن سرویس به ما وجود خطا را اطلاع دهد، لازم داریم تا از وجود خطا در آن سرویس مطلع شویم.