بهار برای تنبل هاست مبانی، مفاهیم اولیه و مثال هایی با کد. قسمت 1

بسیاری از مردم، پس از خواندن مقالات من در مورد ایجاد یک الگو برای یک پروژه وب و در مورد ایجاد یک وب سرویس ساده با استفاده از servlets ، از خود پرسیدند که چه زمانی در مورد Spring بنویسم. من نخواستم، خواندن یک کتاب را پیشنهاد کردم (و هنوز هم می گویم که یک کتاب بهتر از 10 یا حتی 100 مقاله در اینترنت است). اما اکنون تصمیم گرفته‌ام که برای توضیح یک موضوع برای افراد مختلف، زمان بیشتری را صرف می‌کنم تا زمانی که یک بار بنشینم و مقاله‌ای بنویسم و ​​سپس به سادگی پیوندی به آن ارسال کنم. بنابراین من به خاطر پیوند می نویسم)). در این مقاله من نمی نویسم که چگونه یک پروژه کاری در بهار را در 5 دقیقه به دنبال مثال خود بسازیم. من فقط در مورد چیزهای اساسی خواهم نوشت، بدون آگاهی از آنها مطمئناً می توان یک پروژه را شروع کرد، اما آنچه در آنجا اتفاق می افتد، و مهمتر از آن، چرا، مشخص نخواهد بود.

Spring Framework چیست؟

Spring Framework یا به سادگی Spring یکی از محبوب ترین فریم ورک ها برای ایجاد برنامه های کاربردی وب در جاوا است. چارچوب چیزی شبیه به کتابخانه است (شاید این اصطلاح برای شما آشناتر باشد)، اما یک نکته وجود دارد. به طور کلی، با استفاده از یک کتابخانه، شما به سادگی اشیایی از کلاس های موجود در آن ایجاد می کنید، متدهای مورد نیاز خود را فراخوانی می کنید و در نتیجه نتیجه مورد نیاز خود را دریافت می کنید. یعنی یک رویکرد ضروری تری وجود دارد: شما به وضوح در برنامه خود مشخص می کنید که در چه لحظه خاصی باید کدام شی را ایجاد کنید، در چه لحظه ای باید یک متد خاص را فراخوانی کنید و غیره. با فریمورک ها، همه چیز کمی متفاوت است. شما به سادگی برخی از کلاس های خود را می نویسید، بخشی از منطق را در آنجا می نویسید، و خود فریم ورک اشیاء کلاس های شما را ایجاد می کند و متدها را برای شما فراخوانی می کند. اغلب، کلاس‌های شما برخی از اینترفیس‌ها را از فریم‌ورک پیاده‌سازی می‌کنند یا برخی از کلاس‌ها را از آن به ارث می‌برند، بنابراین برخی از عملکردهایی که قبلاً برای شما نوشته شده است را دریافت می‌کنند. اما لازم نیست اینطور باشد. به عنوان مثال، در Spring، آنها سعی می کنند تا حد امکان از چنین جفت سختی دوری کنند (زمانی که کلاس های شما مستقیماً به برخی کلاس ها / رابط های این فریمورک وابسته است) و از حاشیه نویسی برای این منظور استفاده می کنند. بعداً به این نکته باز خواهیم گشت. اما درک این نکته مهم است که Spring فقط مجموعه ای از کلاس ها و رابط هایی است که قبلاً برای شما نوشته شده است :) همچنین می خواهم بلافاصله توجه داشته باشم که Spring را می توان نه تنها برای برنامه های تحت وب، بلکه برای رایج ترین کنسول نیز استفاده کرد. برنامه هایی که برای همه ما بسیار آشنا هستند و امروز ما حتی چیزی شبیه به آن را خواهیم نوشت.

ساختار

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

• دسترسی به داده ها؛
• وب
• هسته؛
• و دیگران.

امروز با برخی از مفاهیم ماژول اصلی مانند: لوبیا، زمینه و غیره آشنا می شویم. همانطور که ممکن است حدس بزنید، ماژول دسترسی به داده حاوی ابزارهایی برای کار با داده ها (عمدتا پایگاه داده)، وب - برای کار در شبکه (از جمله برای ایجاد برنامه های کاربردی وب است که بعداً مورد بحث قرار خواهد گرفت). علاوه بر این، به اصطلاح زیرساخت کل Spring نیز وجود دارد: بسیاری از پروژه های دیگر که به طور رسمی در خود چارچوب گنجانده نشده اند، اما به طور یکپارچه در پروژه Spring شما ادغام شده اند (به عنوان مثال، همان امنیت فنری برای کار با مجوز کاربر در سایتی که امیدوارم روزی ما هم احساسش کنیم).

چرا Spring در جاوا؟

خوب، علاوه بر این که شیک، شیک و جوان پسند است، بلافاصله می توانم بگویم که به محض اینکه حتی کمی به آن مسلط شوید، متوجه خواهید شد که اکنون چقدر کار متفاوتی ندارید و چقدر بهار. بر عهده می گیرد. می توانید چند ده خط پیکربندی بنویسید، چند کلاس بنویسید - و یک پروژه کاری دریافت خواهید کرد. اما به محض اینکه شروع کردید به این فکر کنید که چقدر "زیر هود" وجود دارد، چه مقدار کار در حال انجام است و چه مقدار کد باید نوشته شود اگر همان پروژه را روی سرورهای خالی یا سوکت ها و جاوا خالص انجام دهید. - موهایت سیخ می شود :) حتی چنین تعبیری مانند "جادوی" بهار وجود دارد. این زمانی است که می بینید همه چیز کار می کند، اما تقریباً تخمین می زنید که چقدر باید آنجا اتفاق بیفتد تا همه چیز کار کند و چگونه همه چیز در آنجا کار می کند - پس به نظر می رسد که همه اینها واقعاً به لطف نوعی جادو اتفاق می افتد)) آسان تر است همه آن را جادو بنامید تا اینکه توضیح دهید چگونه همه چیز در آنجا به هم پیوسته است. لبخند data_ web-mvc_ security_ فقط اصول اولیه.

DI/IoC

اگر سعی کردید چیزی را در بهار بخوانید، احتمالاً اولین چیزی که با آن مواجه شدید این حروف بود: DI/IoC . اکنون به شدت توصیه می کنم که از این مقاله فاصله بگیرید و این مقاله را در Habré بخوانید ! IoC (Inversion of Control) - وارونگی کنترل. قبلاً وقتی نوشتم که وقتی از کتابخانه استفاده می کنید به این موضوع اشاره کردم، شما خودتان در کد خود می نویسید که کدام شیء را فراخوانی کنید و در مورد فریمورک ها، اغلب فریم ورک کدی را که در سمت راست نوشته اید فراخوانی می کند. لحظه یعنی در اینجا شما دیگر فرآیند اجرای کد/برنامه را کنترل نمی کنید، بلکه فریم ورک این کار را برای شما انجام می دهد. شما کنترل را به او منتقل کردید (وارونگی کنترل). DI به‌عنوان وارونگی وابستگی (وابستگی وابستگی، یعنی تلاش برای عدم ایجاد اتصالات سخت بین ماژول‌ها/کلاس‌های شما، جایی که یک کلاس مستقیماً به کلاس دیگر متصل است) یا تزریق وابستگی (تزریق وابستگی، زمانی است که اشیاء گربه‌ای نیستند) درک می‌شود. در اصل توسط شما ایجاد می شود و سپس آنها را به روش های خود منتقل می کنید و بهار آنها را برای شما ایجاد می کند و شما فقط به او می گویید "من می خواهم یک گربه اینجا بگیرم" و او آن را در روش شما به شما منتقل می کند). در مقالات بعدی بیشتر با دومی مواجه خواهیم شد.

لوبیا و زمینه

یکی از مفاهیم کلیدی در فصل بهار لوبیا است . در اصل، این فقط یک شی از یک کلاس است. فرض کنید برای برنامه ما باید از 3 شیء استفاده کنیم: یک گربه، یک سگ و یک طوطی. و ما یک دسته کلاس با یک دسته روش داریم که گاهی اوقات برای یک روش به گربه و برای روش دیگر به سگ نیاز داریم و گاهی اوقات روش هایی خواهیم داشت که به یک گربه و یک طوطی (مثلاً یک روش) نیاز داریم. برای غذا دادن به گربه، hehe)، و در برخی روش ها، هر سه شی مورد نیاز خواهد بود. بله، ما می توانیم ابتدا این سه شی را در main ایجاد کنیم و سپس آنها را به کلاس های خود منتقل کنیم و از داخل کلاس ها به متدهای مورد نیاز خود ... و به همین ترتیب در طول برنامه. و اگر همچنین تصور کنیم که به صورت دوره ای می خواهیم لیست پارامترهای پذیرفته شده را برای روش های خود تغییر دهیم (خب، ما تصمیم گرفتیم چیزی را بازنویسی کنیم یا عملکردی را اضافه کنیم) - در صورت نیاز باید تغییرات زیادی در کد انجام دهیم. تغییر دادن چیزی. حال، اگر تصور کنیم که نه 3، بلکه 300 شیء از این دست داریم، چه؟ یک جایگزین این است که همه این اشیاء را در یک لیست مشترک از اشیاء جمع آوری کنیم ( List<Object> ) و آن را به همه متدها منتقل کنیم و از داخل متدها این یا آن شی را که نیاز داریم دریافت کنیم. اما اگر تصور کنیم با پیشرفت برنامه، ممکن است مقداری به این لیست اضافه شود یا (بدتر از آن) حذف شود، چه؟ سپس در تمام روش هایی که اشیاء را از لیست با شاخص آنها بازیابی می کنیم، همه چیز ممکن است خراب شود. سپس تصمیم می گیریم نه یک لیست، بلکه یک نقشه، که در آن کلید، نام شی مورد نیاز ما، و مقدار، خود شی خواهد بود، و سپس می توانیم اشیاء مورد نیاز خود را از آن به سادگی با نام آنها دریافت کنیم. : get("طوطی") و در پاسخ یک طوطی شی دریافت کردیم یا مثلاً کلید کلاس شیء است و مقدار خود شیء است، پس دیگر نمی توانیم نام شیء را نشان دهیم، بلکه به سادگی می توانیم کلاس شی مورد نیاز خود را نشان دهیم که این نیز راحت است. یا حتی نوعی پوشش روی نقشه بنویسید، جایی که می توانید متدهایی ایجاد کنید تا در برخی موارد بتوانید اشیا را با نام آنها و در موارد دیگر با کلاس بازیابی کنید. این چیزی است که ما از زمینه برنامه بهار دریافت می کنیم . زمینه مجموعه ای از لوبیا (اشیاء) است. با عطف به متن، می‌توانیم لوبیا (شیء) مورد نیاز خود را با نام آن مثلاً یا با نوع آن یا چیز دیگری دریافت کنیم. علاوه بر این، می‌توانیم از اسپرینگ بخواهیم که به دنبال لوبیا مورد نیاز ما در زمینه‌اش برود و آن را به روش ما منتقل کند. برای مثال، اگر روشی مانند این داشتیم:

public void doSomething(Cat cat) {
    ...
}

وقتی اسپرینگ این روش را برای ما نامید، شی گربه ما را از بافت خود به آن منتقل کرد. حالا تصمیم می گیریم که روش ما علاوه بر گربه، به طوطی هم نیاز دارد. استفاده از فنر - هیچ چیز برای ما آسان تر نیست! ما به سادگی می نویسیم:

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

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

روش های پیکربندی برنامه

سه راه اصلی برای پیکربندی یک برنامه وجود دارد (یعنی به Spring بگوییم کدام اشیاء باید کار کنیم):

1. استفاده از فایل ها/پیکربندی های xml.
2. استفاده از تنظیمات جاوا؛
3. پیکربندی خودکار

توسعه دهندگان بهار آنها را به ترتیب اولویت ترتیب می دهند:

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

علاوه بر این، Spring به شما اجازه می دهد تا این روش ها را ترکیب کنید. به عنوان مثال، اجازه دهید Spring هر کاری را که می توان به طور خودکار پیکربندی کرد انجام دهد؛ در جایی که باید پارامترهای خاصی را مشخص کنید، آن را با استفاده از تنظیمات جاوا انجام دهید، و علاوه بر این، می توانید برخی از تنظیمات قدیمی را با فرمت xml به هم متصل کنید. به طور کلی، همه اینها را می توان کاملاً انعطاف پذیر انجام داد. اما هنوز، اگر همه چیز را می توان با استفاده از تنظیمات خودکار انجام داد، از آن استفاده کنید. من فقط پیکربندی خودکار و تنظیمات جاوا را در نظر خواهم گرفت. پیکربندی‌های xml تقریباً در هر نمونه Spring در اینترنت استفاده می‌شوند، و هنگامی که متوجه شدید که پیکربندی جاوا چگونه کار می‌کند، مشکلی در «خواندن» یک فایل xml که همان کار را انجام می‌دهد وجود ندارد. پیکربندی خودکار زمانی استفاده می‌شود که اشیایی که برای کار به آن نیاز داریم، اشیاء کلاس‌هایی هستند که نوشته‌ایم . اگر منطق بسیار خاصی برای ایجاد یک شی از کلاس خود مورد نیاز است، یا اگر فرصتی برای علامت گذاری برخی از کلاس ها با حاشیه نویسی مورد نیاز خود نداریم، که توسط پیکربندی خودکار انتخاب می شود، این کار را می توان در تنظیمات جاوا انجام داد. . در قسمت بعدی ، ما یک پروژه maven ایجاد می کنیم، چند ماژول فنر مرکزی را به آن متصل می کنیم و اولین دانه های خود را ایجاد می کنیم.