در یک برنامه اسپرینگ، کلاسهایی که کار اصلی را میکنند هیچوقت با new ساخته نمیشوند. فریمورک آنها را پیدا میکند، یک نمونه میسازد، و هر چیزی را که سازندهشان میخواهد خودش پاس میدهد.
یک مسیر کامل که به یک درخواست جواب میدهد، سه حاشیهنویسی است:
@RestControllerروی کلاس، که متدهایش را پاسخدهنده HTTP میکند@GetMapping("/qetat/{kod}")روی متد، که مسیر را به آن میبندد@PathVariable String kodروی پارامتر، که بخش متغیر مسیر را به آرگومان میبندد
مقدار برگشتی متد خودش به JSON تبدیل میشود و لازم نیست کاری بکنید. اگر کلاس فقط یک سازنده داشته باشد، هیچ حاشیهنویسیای روی سازنده لازم نیست و اسپرینگ همان را استفاده میکند؛ این از نسخههای قدیمیتر عوض شده و کد قدیمی هنوز حاشیهنویسی اضافه دارد.
تزریق از راه سازنده، و نه از راه فیلد
دو راه برای گرفتن وابستگی هست و یکیشان تقریبا همیشه اشتباه است. تزریق روی فیلد کوتاهتر به نظر میرسد و سه هزینه دارد: کلاس را بدون فریمورک نمیشود ساخت، پس آزمون واحد نوشتن برایش سخت میشود؛ فیلد نمیتواند نهایی باشد؛ و از امضای کلاس معلوم نیست به چه چیزهایی نیاز دارد.
سازنده هر سه را حل میکند و هیچ چیزی هم اضافه نمیخواهد. علامتی که میگوید طراحی خراب شده هم همینجا دیده میشود: سازندهای با هفت پارامتر یعنی این کلاس هفت کار میکند، که همان اصل اول در پنج اصل، و اینکه هرکدام جلوی چه چیزی را میگیرد است.
سه لایه، و مرزی که نباید شکسته شود
لایه کنترلر فقط ترجمه میکند: درخواست را میگیرد، به یک فراخوانی تبدیل میکند، و نتیجه را به پاسخ برمیگرداند. لایه سرویس منطق کسبوکار است و باید بدون هیچ چیزی از HTTP قابل آزمون باشد. لایه مخزن با پایگاه داده حرف میزند.
مرزی که در عمل زیاد شکسته میشود مرز اول است: نوشتن منطق داخل کنترلر. نتیجهاش این است که برای آزمودن یک محاسبه ساده باید کل زمینه وب بالا بیاید و آزمون از چند میلیثانیه به چند ثانیه میرود. علامتش هم ساده است: اگر کنترلر بیش از چند سطر دارد، منطق جایش عوض شده.
جایی که کار گیر میکند، دانلود وابستگیهاست
اولین ساخت یک پروژه اسپرینگ صدها بسته را از مخزن مرکزی میگیرد و همان مرحله است که از ایران معمولا شکست میخورد یا ساعتها طول میکشد. راهحلی که تیمها استفاده میکنند تنظیم یک آینه در فایل تنظیمات ابزار ساخت است، و پس از آن، پوشه کش محلی همه چیز را نگه میدارد و ساختهای بعدی آفلاین کار میکنند. اگر روی چند ماشین کار میکنید، همان پوشه کش را کپی کنید؛ زشت است و روزها وقت میخرد. نکته دومی که کمتر گفته میشود این است که هر بار نسخه اسپرینگ را بالا میبرید، همان مرحله از نو تکرار میشود، پس ارتقا را زمانی برنامهریزی کنید که وقت دارید.
ابزار، و سالی که این حرف درست است
در سال ۲۰۲۶ نقطه شروع Spring Boot است و نه اسپرینگ خالی؛ جای فایلهای پیکربندی XML را گرفته که تا حدود سال ۲۰۱۴ استاندارد بودند، و یک برنامه اجرایی با سرور توکار تحویل میدهد. متنباز و رایگان است. برای ساختن اسکلت پروژه، سایت رسمی تولید پروژه همان کار را در یک صفحه انجام میدهد و خروجیاش یک آرشیو است، که یعنی میشود یک بار گرفت و بارها استفاده کرد.
پرسش بعدی این است که لایه مخزن چطور سطرها را به شی تبدیل میکند و چه چیزی از زیرش بیرون میزند، که کار با داده در کد است. و مسیر کامل یک درخواست، مستقل از فریمورک، در درخواست میآید، پاسخ میرود، و هرچه میان این دو است باز میشود.