از Hello World تا Spring Web MVC و servlets چه ربطی به آن دارد

معرفی

همانطور که می دانیم، موفقیت جاوا دقیقاً به لطف تکامل نرم افزارهایی است که برای اتصال به شبکه تلاش می کنند. بنابراین، ما برنامه معمولی کنسول " Hello World " را به عنوان مبنایی در نظر می گیریم و درک می کنیم که برای تبدیل شدن به یک برنامه شبکه از یک برنامه کنسول به چه چیزی نیاز دارد. بنابراین، ابتدا باید یک پروژه جاوا ایجاد کنید. برنامه نویسان افراد تنبلی هستند. در دوران ماقبل تاریخ، زمانی که برخی در حال شکار ماموت بودند، برخی دیگر می نشستند و سعی می کردند در انواع کتابخانه های جاوا و ساختارهای دایرکتوری گیج نشوند. به طوری که توسعه دهنده می تواند روند ایجاد یک برنامه را کنترل کند، به طوری که بتواند به سادگی بنویسد "من یک کتابخانه از فلان نسخه 2 می خواهم"، آنها با ابزارهای ویژه - ساخت سیستم ها آمدند. دو معروف ترین آنها Maven و Gradle هستند . برای این مقاله از Gradle استفاده خواهیم کرد. اگر قبلاً مجبور بودیم ساختار دایرکتوری را خودمان ایجاد کنیم، اکنون Gradle با استفاده از پلاگین Gradle Init به ما اجازه می دهد یک پروژه جاوا با ساختار دایرکتوری و کلاس اصلی اصلی در یک دستور ایجاد کنیم: gradle init --type java-application این دستور مقدار دهی اولیه (init) را برای آن انجام می دهد. ما یک برنامه جاوا (java-application) با کنسول Hello World. پس از تکمیل، یک فایل در دایرکتوری ظاهر می شود - build.gradle . این اسکریپت ساخت ما است - یعنی یک اسکریپت خاص برای ایجاد یک برنامه با شرح اقداماتی که برای این کار باید انجام شود. بیایید آن را باز کنیم و خط را به آن اضافه کنیم: jar.baseName = 'webproject' Gradle به شما اجازه می دهد تا اقدامات مختلفی را روی یک پروژه انجام دهید و این اقدامات را task می نامند . با اجرای یک دستور (وظیفه) یک فایل JAR gradle buildدر پوشه /build/libs ایجاد می شود . و همانطور که حدس زدید، نام آن اکنون webproject.jar خواهد بود . اما اگر اجرا کنیم java -jar ./build/libs/webproject.jarبا خطا مواجه می شویم: no main manifest attribute. این به این دلیل است که برای یک برنامه جاوا باید یک مانیفست را ضمیمه کنید - این توضیحی در مورد نحوه کار با برنامه، نحوه درک آن است. سپس JVM که برنامه جاوا را اجرا می کند، می داند که کدام کلاس نقطه ورود به برنامه و سایر اطلاعات است (مثلاً classpath). اگر به محتویات بیلد اسکریپت نگاه دقیق تری بیندازیم، شاهد اتصال افزونه ها خواهیم بود. به عنوان مثال: اگر به صفحه پلاگین جاوا Gradleapply plugin: 'java' برویم ، می بینیم که می توانیم مانیفست را پیکربندی کنیم:

jar {
    manifest {
        attributes 'Main-Class': 'App'
    }
}

کلاس اصلی، نقطه ورود به برنامه، توسط پلاگین Gradle Init برای ما ایجاد شد. و حتی در پارامتر mainClassName مشخص شده است. اما این برای ما مناسب نبود، زیرا ... این تنظیم به افزونه دیگری، Gradle Application Plugin اشاره دارد . بنابراین، ما یک برنامه جاوا داریم که Hello World را روی صفحه نمایش می دهد. این برنامه جاوا در یک JAR (Java ARchive) بسته بندی شده است. این ساده است، مبتنی بر کنسول است، به روز نیست. چگونه آن را به یک برنامه وب تبدیل کنیم؟

Servlet API

برای اینکه جاوا بتواند با شبکه کار کند، مشخصاتی به نام Servlet API در دوران باستان ظاهر شد . این مشخصات است که تعامل مشتری و سرور، دریافت پیام از یک مشتری (مثلاً مرورگر) و ارسال پاسخ (مثلاً با متن یک صفحه) را توصیف می کند. طبیعتاً از آن زمان تا کنون خیلی چیزها تغییر کرده است، اما نکته اینجاست که برای اینکه یک برنامه جاوا به یک برنامه وب تبدیل شود، از Servlet API استفاده می شود. برای اینکه گمانه زنی های بی اساس نداشته باشیم، بیایید همین مشخصات را انتخاب کنیم: JSR-000340 JavaTM Servlet 3.1 . اول از همه، ما به " فصل 1: مرور کلی " علاقه مندیم . مفاهیم اساسی را که ما باید درک کنیم را شرح می دهد. اولاً، سرولت چیست؟ فصل " 1.1 Servlet چیست؟ " می گوید که Servlet یک جزء جاوا است که توسط یک کانتینر مدیریت می شود و محتوای پویا تولید می کند. مانند سایر اجزای جاوا، servlet یک کلاس جاوا است که در بایت کد کامپایل می شود و می تواند با استفاده از فناوری جاوا در یک وب سرور بارگذاری شود. مهم است که سرولت ها با یک سرویس گیرنده وب (به عنوان مثال، یک مرورگر) در چارچوب الگوی درخواست/پاسخ که توسط کانتینر Servlet پیاده سازی می شود، تعامل داشته باشند. معلوم می شود که Servlets در نوعی از Servlet Container زندگی می کنند. این چیه؟ در فصل " 1.2 کانتینر Servlet چیست؟ " گفته می شود که کانتینر Servlet بخشی از وب سرور یا سرور برنامه است که خدمات شبکه ای را ارائه می دهد که از طریق آن درخواست ها ارسال می شود و پاسخ ها ارسال می شود. همین Servlet Container چرخه حیات servlet ها را مدیریت می کند. همه کانتینرهای Servlet باید حداقل از پروتکل HTTP پشتیبانی کنند، اما ممکن است سایرین را پشتیبانی کنند. به عنوان مثال، HTTPS. همچنین مهم است که کانتینر Servlet بتواند هر گونه محدودیت مرتبط با امنیت را در محیطی که سرولت ها در آن اجرا می شوند اعمال کند. همچنین مهم است که طبق " فایل بایگانی برنامه وب 10.6 " برنامه وب باید در یک فایل WAR (Web ARchive) بسته بندی شود. یعنی اکنون باید پلاگین های jar و اپلیکیشن خود را برای چیز دیگری حذف کنیم. و این پلاگین Gradle WAR است . و به جای jar.baseName، war.baseName Why را مشخص کنید از آنجایی که دیگر از افزونه jar استفاده نمی کنیم، تنظیمات مانیفست را نیز حذف کرده ایم. هنگامی که ما JAR را راه اندازی کردیم، ماشین مجازی جاوا (JVM) باید از طریق مانیفست نحوه کار با برنامه ما را توضیح می داد. زیرا JVM آن را اجرا می کرد. برنامه وب، ظاهراً توسط نوعی وب سرور اجرا می شود. معلوم می شود که او باید به نوعی به او بگوید که چگونه با برنامه وب ما کار کند؟ و معلوم می شود که بله. برنامه های کاربردی وب مانیفست خاص خود را دارند. Deployment Descriptor نامیده می شود . یک بخش کامل به آن اختصاص داده شده است: " 14. Deployment Descriptor ". یک بخش مهم وجود دارد: " فصل 10:". در مورد اینکه یک برنامه وب از دیدگاه Servlet API چیست صحبت می کند. به عنوان مثال، در فصل " ساختار راهنمای 10.5 " مشخص شده است که Deployment Descriptor باید کجا باشد: /WEB-INF/web.xmlWEB-INF کجا قرار گیرد؟ همانطور که در پلاگین Gradle WAR گفته شد، یک طرح بندی جدید اضافه می کند : src/main/webappبنابراین، اجازه دهید چنین دایرکتوری ایجاد کنیم، داخل یک پوشه WEB-INF و در داخل یک فایل web.xml ایجاد می کنیم. مهم است که دایرکتوری WEB-INF نامیده می شود و نه META-INF! بیایید آن را از مثال XML " 14.5.1 A Basic Example " کپی کنیم: همانطور که می بینیم، یک سند XML برای پیکربندی استفاده می شود. یک سند XML، برای اینکه معتبر (معتبر) در نظر گرفته شود، باید با برخی «شما» مطابقت داشته باشد. شما می توانید این را به عنوان نوعی رابط برای یک سند XML در نظر بگیرید. این طرح مشخص می کند که چه عناصری می تواند در یک سند XML باشد، چه نوع داده ای می تواند عنصر، ترتیب، نیاز و سایر جنبه ها را تعریف کند. مثال کپی شده از مستندات نسخه 2.5 را نشان می دهد، اما ما می خواهیم از نسخه 3.1 استفاده کنیم. طبیعتاً با تغییر نسخه ها، مشخصات تغییر کرد و ویژگی های جدیدی به آن اضافه شد. بنابراین، باید از طرحی غیر از طرح مورد استفاده برای نسخه 2.5 (web-app_2_5.xsd) استفاده کنید. از چه طرحی برای نسخه 3.1 استفاده کنم؟ مستندات در این مورد به ما کمک خواهند کرد، فصل " 14.3 Deployment Descriptor "، که بیان می specification is available at http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd کند، باید پیوند طرح را با xsd مشخص شده در همه جا جایگزین کنیم، فراموش نکنیم که آن را version="2.5"به 3.1 تغییر دهیم، و همچنین فضای نام را در همه جا تغییر دهیم ( xmlns و در xsi:schemaLocation). آنها نشان می دهند که ما در کدام فضای نام کار خواهیم کرد (به بیان ساده، از چه نام عناصری می توانیم استفاده کنیم). اگر فایل طرحواره را باز کنید، targetNamespace حاوی همان فضای نامی است که باید مشخص کنیم: همانطور که به یاد داریم، در فایل Manifest of the Jar نوشتیم که از کدام کلاس می خواهیم استفاده کنیم. اینجا چه باید کرد؟ در اینجا باید مشخص کنیم که وقتی درخواستی از یک سرویس گیرنده وب دریافت می کنیم، می خواهیم از کدام کلاس servlet استفاده کنیم. توضیحات را می توان در فصل " 14.4 Deployment Descriptor Diagram " خواند. شبیه این خواهد شد: اینجا همه چیز ساده است. سرورلت اعلام می شود و سپس به یک الگوی خاص نگاشت می شود. در این مورد، در /app. هنگامی که قالب اجرا می شود، متد servlet اجرا می شود. برای زیبایی، کلاس App باید به بسته منتقل شود، بدون اینکه تنظیمات xml را اصلاح کنید. اما این همه ماجرا نیست. برنامه باید یک servlet باشد. سرولت بودن به چه معناست؟ این بدان معنی است که ما باید از HttpServlet ارث ببریم . یک مثال را می توان در فصل " 8.1.1 @WebServlet " مشاهده کرد. طبق آن، کلاس App ما به شکل زیر خواهد بود:

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class App extends HttpServlet {
    public String getGreeting() {
        return "Hello world.";
    }

	public void doGet(HttpServletRequest request, HttpServletResponse response) {
		response.setContentType("text/html");
		try {
			response.getWriter().println(getGreeting());
		} catch (IOException e) {
			throw new IllegalStateException(e);
		}
	}
}

اما پروژه ما هنوز آماده نیست. زیرا ما اکنون به Servlet API نسخه 3.1 وابسته هستیم. این بدان معناست که در اسکریپت ساختمان باید وابستگی به Servlet API را نشان دهیم. JVM باید بداند آنچه در کد نوشته اید صحیح است و چگونه از آن استفاده کند. همانطور که به یاد داریم، مشخصات اساساً فقط رابط‌هایی هستند که نحوه عملکرد آن را توصیف می‌کنند. و پیاده سازی ها در سمت وب سرور قرار دارند. بنابراین، بدون Servlet API، یک کتابخانه مورد نیاز در Maven Central وجود خواهد داشت: javax.servlet-api . و یک ورودی به بلوک وابستگی ها اضافه کنید . در مخزن Maven همانطور که دیدید می گوید ارائه شده است. قبل از استفاده از وابستگی، باید محدوده را مشخص کنید. Gradle محدوده ای به نام "ارائه شده" ندارد، اما دارای دامنه " فقط کامپایل " است. بنابراین، نشان خواهیم داد: providedCompile 'javax.servlet:javax.servlet-api:3.1.0' اوه، به نظر می رسد همه چیز خوب است؟ Gradle Build پروژه ما را در یک فایل WAR می سازد. و بعد با آن چه کنیم؟ ابتدا به یک وب سرور نیاز داریم. در گوگل ما می نویسیم " وب سرور جاوا لیست " و لیستی از وب سرورها را می بینیم. بیایید از این لیست، به عنوان مثال، TomCat را انتخاب کنیم . به وب سایت آپاچی تامکت بروید ، آخرین نسخه (در حال حاضر نسخه 9) را به عنوان یک آرشیو فشرده (اگر برای ویندوز) دانلود کنید. آن را در فهرستی باز کنید. هورا، ما یک وب سرور داریم. از دایرکتوری وب سرور در زیر شاخه bin ، کاتالینا را از خط فرمان اجرا می کنیم و گزینه های موجود را مشاهده می کنیم. بیایید انجام دهیم: catalina start. هر وب سرور دارای یک دایرکتوری است که وب سرور آن را نظارت می کند. اگر یک فایل برنامه وب در آنجا ظاهر شود، وب سرور شروع به نصب آن می کند. به این نصب Deployment یا Deployment می گویند . بله بله، به همین دلیل است که " Deployment Descriptor ". یعنی چگونه برنامه را به درستی مستقر کنیم. در Tomcat این دایرکتوری webapps است . بیایید جنگی را که با استفاده از gradle build در آنجا ساختیم کپی کنیم. پس از این، در لاگ چیزی شبیه به این خواهیم دید: Deployment of web application archive [tomcat\webapps\webproject.war] has finished in [время] ms برای درک بهتر، در پوشه tomcat فایل را ویرایش می کنیم \conf\tomcat-users.xmlو خطوط زیر را اضافه می کنیم: حالا سرور را ریستارت می کنیم (catalina stop, catalina start) و به آدرس می رویم http://127.0.0.1:8080/manager در اینجا مسیرهای تمامی اپلیکیشن ها را می بینیم. به احتمال زیاد به پروژه وب ما مسیر /webproject داده شده است. این مسیر چیست؟ مشخصات در فصل " 10.1 برنامه های کاربردی وب در سرورهای وب " بیان می کند که یک برنامه وب با مسیری در داخل برنامه مرتبط است (در این مورد، /webproject). تمام درخواست ها از طریق این مسیر با همان ServletContext مرتبط خواهند شد. این مسیر همچنین contextRoot نامیده می شود . و طبق " 10.2 رابطه با ServletContext " کانتینر servlet برنامه وب و ServletContext را یک به یک مرتبط می کند. یعنی هر برنامه تحت وب ServletContext خود را دارد. ServletContext چیست ؟ همانطور که مشخصات بیان می کند، یک ServletContext یک شی است که سرولت ها را با "نمای برنامه " که در آن در حال اجرا هستند ارائه می دهد. Context Servlet با جزئیات بیشتر در فصل 4 مشخصات Servlet API توضیح داده شده است. با کمال تعجب، Servlet API در نسخه 3.1 دیگر نیازی به وجود web.xml ندارد. به عنوان مثال، می توانید یک servlet را با استفاده از حاشیه نویسی تعریف کنید:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/app2")
public class App2 extends HttpServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.setContentType("text/html");
        response.getWriter().println("app2");
    }
}

همچنین در مورد این موضوع توصیه می شود: " مصاحبه Java EE - JEE Servlet API (سوالات و پاسخ ها) ". بنابراین، ما یک Servlet داریم - مسئول پاسخگویی به مشتری وب است. ما یک ServletContainer داریم که درخواست‌های کاربر را دریافت می‌کند، مسیری را که به آن دسترسی داشته‌اید با مسیر servlet مطابقت می‌دهد، و اگر مطابقتی پیدا شود، Servlet را اجرا می‌کند. خوب. بهار چه جایگاهی در این تصویر از جهان دارد ؟

اسپرینگ وب MVC

عالی است، ما یک برنامه وب داریم. حالا باید Spring را وصل کنیم. ما چطوری می تونیم این کار را انجام بدهیم؟ ابتدا باید نحوه اتصال صحیح Spring را به پروژه خود بیابید. به نظر می رسد که قبلاً مطابق با مستندات پروژه پلتفرم Spring امکان انجام این کار وجود داشت ، اما اکنون " پلتفرم در 9 آوریل 2019 به پایان عمر پشتیبانی شده خود می رسد " ، یعنی توصیه نمی شود که از آن استفاده کنید، زیرا به زودی دیگر پشتیبانی نخواهد شد. تنها راه خروج این است که " کاربران پلتفرم تشویق می شوند تا از مدیریت وابستگی Spring Boot استفاده کنند ". بنابراین، اجازه دهید به مستندات Spring Boot برویم . اجازه دهید توضیح دهم که ما از خود Spring Boot استفاده نمی کنیم، بلکه فقط از Dependency Management از Spring Boot استفاده می کنیم. به این معنا که پروژه Spring Boot می تواند دانشی را در مورد نسخه هایی از کتابخانه ها (از جمله Spring MVC) ارائه دهد. در آنجا 3.2 را خواهیم یافت . استفاده از مدیریت وابستگی Spring Boot به صورت مجزا . با توجه به مستندات، موارد زیر را به اسکریپت ساخت اضافه کنید:

plugins {
    id 'org.springframework.boot' version '2.0.4.RELEASE' apply false
}
apply plugin: 'io.spring.dependency-management'

و

dependencyManagement {
    imports {
        mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
    }
}

همانطور که می بینید، ما اشاره کردیم apply false، i.e. ما از خود Spring Boot استفاده نمی کنیم، اما از مدیریت وابستگی از آنجا استفاده می کنیم. به این مدیریت وابستگی، BOM - " Bill Of Materials " نیز می‌گویند . اکنون آماده هستیم تا خود پروژه Spring Web MVC را متصل کنیم. Spring Web MVC بخشی از پروژه Spring Framework است و ما به بخش " Web Servlet " علاقه مندیم . بیایید وابستگی را به اسکریپت ساخت اضافه کنیم: compile 'org.springframework:spring-webmvc'. همانطور که می بینیم، کامپایل دامنه را تنظیم می کنیم، زیرا سرور وب بهار را در اختیار ما قرار نمی دهد. پروژه ما مجبور است کتابخانه Spring را در داخل خود گنجانده باشد. در مرحله بعد، خواندن بخش " 1.2. DispatcherServlet " برای ما مهم است، جایی که گفته می شود Spring MVC حول الگوی " Front Controller " ساخته شده است ، جایی که نوعی سرویس دهنده مرکزی وجود دارد که پیکربندی و تفویض را به اجزای دیگر ارائه می دهد. . Dispatcher را می توان به عنوان Dispatcher ترجمه کرد. بنابراین، اول از همه، در web.xml اعلام می کنیم: همانطور که می بینیم، این در واقع یک listener معمولی است که در مشخصات Servlet API تعریف شده است. برای دقیق تر، این یک ServletContextListener است، یعنی برای مقداردهی اولیه Servlet Context برای برنامه وب ما راه اندازی می شود. در مرحله بعد، باید تنظیماتی را مشخص کنید که به Spring می گوید که پیکربندی xml مخصوص آن با تنظیمات در کجا قرار دارد: همانطور که می بینید، این فقط یک تنظیم معمولی است که در سطح Servlet Context ذخیره می شود، اما در هنگام مقداردهی اولیه Application Context توسط Spring استفاده می شود. اکنون باید به جای همه servlet ها، یک توزیع کننده واحد اعلام کنید که همه درخواست های دیگر را توزیع می کند. و هیچ جادویی در اینجا وجود ندارد. اگر نگاه کنیم، این یک HttpServlet است، دقیقاً جایی که Spring کارهای زیادی انجام می دهد که آن را به یک چارچوب تبدیل می کند. تنها چیزی که باقی می ماند این است که یک الگوی URL خاص را با servlet مرتبط کنیم (نقشه برداری کنیم): همه چیز مثل قبل است. حالا بیایید چیزی بسازیم که وب سرور ما باید نمایش دهد. به عنوان مثال، بیایید یک زیر شاخه صفحات در WEB-INF خود ایجاد کنیم و یک فایل hello.jsp وجود خواهد داشت. محتوا می تواند ابتدایی ترین باشد. به عنوان مثال، در داخل تگ های html یک تگ h1 با متن " Hello World " وجود دارد. و فراموش نکنید که فایلی را applicationContext.xmlکه قبلا مشخص کردیم ایجاد کنید. بیایید یک مثال از مستندات Spring را در نظر بگیریم: " 1.10.3. شناسایی خودکار کلاس ها و ثبت تعاریف bean ". زیرا ما تشخیص خودکار را از این طریق فعال می‌کنیم، اکنون می‌توانیم 2 کلاس ایجاد کنیم (به دلیل استفاده از حاشیه‌نویسی‌های ویژه Spring آنها به عنوان Spring Beans در نظر گرفته می‌شوند)، که Spring اکنون خودش ایجاد می‌کند و برنامه ما را با کمک آنها سفارشی می‌کند:

1. پیکربندی وب به عنوان مثال پیکربندی سبک جاوا:

   @Configuration
   @EnableWebMvc
   public class WebConfig implements WebMvcConfigurer {
       @Override
       public void configureViewResolvers(ViewResolverRegistry registry) {
           registry.jsp("/WEB-INF/pages/", ".jsp");
       }
       @Override
       public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
           configurer.enable();
       }
   }

   این مثال در مستندات Spring Framework توضیح داده شده است: " 1.11. MVC Config ".

   در اینجا یک ViewResolver ثبت می کنیم که به تعیین محل قرارگیری صفحات jsp کمک می کند. روش دوم تضمین می کند که " سرویس پیش فرض " فعال است.

   شما می توانید در این مورد بیشتر بخوانید: " نیاز و استفاده از default-servlet-handler چیست ".

2. کنترلر HelloController برای توصیف نگاشت درخواست ها به یک JSP خاص

   @Controller
   public class HelloController {
       @GetMapping("/hello")
       public String handle(Model model) {
           return "hello";
       }
   }

   در اینجا ما از حاشیه نویسی @Controller که در مستندات فصل " 1.4. Annotated Controllers " توضیح داده شده است استفاده کرده ایم.

اکنون، هنگامی که برنامه ما مستقر می شود، وقتی درخواستی را ارسال می کنیم /webproject/hello(که در آن /webproject ریشه متن است)، ابتدا DispatcherServlet پردازش می شود. او به عنوان توزیع کننده اصلی تعیین می کند که ما /* با درخواست فعلی مطابقت دارد، به این معنی که DispatcherServlet باید کاری انجام دهد. سپس تمام نگاشت هایی را که پیدا می کند مرور می کند. مشاهده می کند که یک HelloController با متد handle وجود دارد که به /hello نگاشت شده است و آن را اجرا می کند. این روش متن "hello" را برمی گرداند. این متن توسط ViewResolver دریافت می‌شود، که به سرور می‌گوید کجا باید فایل‌های jsp را که باید به مشتری نمایش داده شوند، جستجو کند. بنابراین، مشتری در نهایت آن صفحه بسیار گرامی را دریافت خواهد کرد.

نتیجه

امیدوارم از مقاله مشخص شود که کلمه "زمینه" ترسناک نیست. معلوم می شود که مشخصات بسیار مفید است. و سند دوست ماست نه دشمن ما. امیدوارم مشخص شود که Spring بر اساس چه چیزی ساخته شده است، چگونه متصل می شود و Servlet API چه ربطی به آن دارد.