Mùa xuân dành cho những kẻ lười biếng. Nguyên tắc cơ bản, khái niệm cơ bản và ví dụ về mã. Phần 1

Nhiều người, sau khi đọc các bài viết của tôi về việc tạo mẫu cho một dự án web và về việc tạo một dịch vụ web đơn giản bằng cách sử dụng servlets , đã tự hỏi khi nào tôi sẽ viết về Spring. Tôi không muốn, tôi đề nghị đọc một cuốn sách (và tôi vẫn nói rằng một cuốn sách tốt hơn 10, thậm chí 100 bài viết trên Internet). Nhưng bây giờ tôi quyết định rằng việc giải thích điều tương tự cho những người khác nhau, tôi sẽ dành nhiều thời gian hơn là ngồi xuống viết một bài báo rồi chỉ đăng một liên kết tới bài báo đó. Vì vậy, tôi viết vì lợi ích của liên kết)). Trong bài viết này, tôi sẽ không viết cách tạo một dự án hoạt động được trong Spring trong 5 phút theo ví dụ của tôi. Tôi sẽ chỉ viết về những điều cơ bản mà không có kiến ​​thức về những điều đó thì chắc chắn có thể bắt đầu một dự án, nhưng điều gì đang xảy ra ở đó và quan trọng hơn là tại sao thì sẽ không rõ ràng.

Khung mùa xuân là gì?

Spring Framework , hay đơn giản là Spring , là một trong những framework phổ biến nhất để tạo các ứng dụng web bằng Java. Framework là một cái gì đó tương tự như một thư viện (có lẽ thuật ngữ này quen thuộc hơn với bạn), nhưng có một điểm. Nói một cách đại khái, bằng cách sử dụng một thư viện, bạn chỉ cần tạo các đối tượng của các lớp trong đó, gọi các phương thức bạn cần và từ đó nhận được kết quả bạn cần. Nghĩa là, có một cách tiếp cận cấp bách hơn: bạn chỉ rõ trong chương trình của mình vào thời điểm cụ thể nào bạn cần tạo đối tượng nào, vào thời điểm nào bạn cần gọi một phương thức cụ thể, v.v. Với các framework, mọi thứ hơi khác một chút. Bạn chỉ cần viết một số lớp của riêng mình, viết một số phần logic vào đó và chính khung công tác đó sẽ tạo các đối tượng của lớp và gọi các phương thức cho bạn. Thông thường, các lớp của bạn triển khai một số giao diện từ khung công tác hoặc kế thừa một số lớp từ khung đó, do đó nhận được một số chức năng đã được viết sẵn cho bạn. Nhưng nó không nhất thiết phải như vậy. Ví dụ, trong Spring, họ cố gắng tránh xa sự kết hợp chặt chẽ như vậy càng nhiều càng tốt (khi các lớp của bạn phụ thuộc trực tiếp vào một số lớp/giao diện từ khung này) và sử dụng các chú thích cho mục đích này. Chúng ta sẽ quay lại điểm này sau. Nhưng điều quan trọng là phải hiểu rằng Spring chỉ là một tập hợp một số lớp và giao diện đã được viết cho bạn :) Tôi cũng muốn lưu ý ngay rằng Spring không chỉ có thể được sử dụng cho các ứng dụng web mà còn cho bảng điều khiển phổ biến nhất những ứng dụng đã quá quen thuộc với tất cả chúng ta Và hôm nay chúng tôi thậm chí sẽ viết một cái gì đó như thế.

Kết cấu

Nhưng Spring không phải là một framework cụ thể. Đây đúng hơn là tên chung cho một số khung công tác nhỏ, mỗi khung thực hiện một số công việc khác nhau. Như bạn có thể thấy, lò xo có cấu trúc mô-đun. Điều này cho phép chúng tôi chỉ kết nối những mô-đun mà chúng tôi cần cho ứng dụng của mình và không kết nối những mô-đun mà chúng tôi rõ ràng sẽ không sử dụng. Theo tôi được biết, chính cách tiếp cận này đã giúp Spring vượt qua đối thủ lúc bấy giờ (EJB) và vươn lên dẫn đầu. Bởi vì các ứng dụng sử dụng EJB kéo theo rất nhiều sự phụ thuộc với chúng và nhìn chung chúng trở nên chậm và vụng về. Hình ảnh cho thấy khung lò xo bao gồm một số mô-đun:

• truy cập dữ liệu;
• mạng;
• cốt lõi;
• và những người khác.

Hôm nay chúng ta sẽ làm quen với một số khái niệm của mô-đun chính, chẳng hạn như: đậu, ngữ cảnh và những khái niệm khác. Như bạn có thể đoán, mô-đun truy cập dữ liệu chứa các công cụ để làm việc với dữ liệu (chủ yếu là cơ sở dữ liệu), web - để làm việc trên mạng (bao gồm cả việc tạo các ứng dụng web, sẽ được thảo luận sau). Ngoài ra, còn có cái gọi là toàn bộ cơ sở hạ tầng Spring: nhiều dự án khác không được đưa chính thức vào framework nhưng được tích hợp liền mạch vào dự án Spring của bạn (ví dụ: cùng một bảo mật mùa xuân để làm việc với ủy quyền của người dùng trên trang web mà tôi hy vọng một ngày nào đó chúng ta cũng sẽ cảm nhận được).

Tại sao lại có mùa xuân trong Java?

Chà, bên cạnh việc nó thời trang, sành điệu và trẻ trung, tôi có thể nói ngay rằng ngay khi bạn nắm vững nó dù chỉ một chút, bạn sẽ hiểu bây giờ bạn không phải làm bao nhiêu công việc khác nhau và bao nhiêu mùa xuân. mặc vào. Bạn có thể viết vài chục dòng cấu hình, viết một vài lớp - và bạn sẽ có được một dự án hoạt động được. Nhưng ngay khi bạn bắt đầu nghĩ về việc có bao nhiêu “ẩn”, bao nhiêu công việc đang được thực hiện và bao nhiêu mã sẽ phải được viết nếu bạn thực hiện cùng một dự án trên các servlet trần hoặc trên các ổ cắm và Java thuần túy - dựng tóc gáy :) Thậm chí còn có một biểu hiện như vậy: giống như "ma thuật" của Mùa xuân. Đây là khi bạn thấy rằng mọi thứ đang hoạt động, nhưng bạn ước tính đại khái mức độ phải xảy ra ở đó để mọi thứ hoạt động và mọi thứ hoạt động như thế nào ở đó - khi đó có vẻ như tất cả những điều này xảy ra thực sự là nhờ vào một loại phép thuật nào đó)) Dễ dàng hơn để gọi nó là tất cả ma thuật hơn là cố gắng giải thích làm thế nào tất cả được kết nối với nhau ở đó. :) Chà, lập luận thứ hai “cho” học Mùa xuân là trong khoảng 90% vị trí tuyển dụng dành cho học sinh cuối cấp (theo quan sát cá nhân của tôi), hoặc là kiến ​​thức hoặc ít nhất là một ý tưởng chung về bộ mùa Xuân của quý ông từ data, web-mvcvà security:) chỉ cần những điều cơ bản.

DI/IoC

Nếu bạn cố đọc thứ gì đó trên Spring, thì điều đầu tiên bạn gặp có lẽ là những chữ cái sau: DI/IoC . Bây giờ tôi thực sự khuyên bạn nên tạm dừng bài viết này và đọc bài viết này trên Habré ! IoC (Đảo ngược điều khiển) - đảo ngược điều khiển. Tôi đã đề cập đến điều này khi tôi viết rằng khi sử dụng thư viện, chính bạn sẽ viết vào mã của mình phương thức nào sẽ gọi đối tượng nào và trong trường hợp các khung, hầu hết khung sẽ gọi mã mà bạn đã viết ở bên phải chốc lát. Nghĩa là, ở đây bạn không còn kiểm soát quá trình thực thi mã/chương trình nữa mà khung công tác sẽ thực hiện việc đó cho bạn. Bạn đã chuyển quyền kiểm soát cho anh ấy (đảo ngược quyền kiểm soát). DI được hiểu là Đảo ngược phụ thuộc (đảo ngược phụ thuộc, nghĩa là cố gắng không tạo kết nối cứng giữa các mô-đun/lớp của bạn, trong đó một lớp được liên kết trực tiếp với lớp khác) hoặc Dependency Insert (đảo phụ thuộc, đây là khi các đối tượng mèo không do bạn tạo ra trong phần chính và sau đó bạn chuyển chúng cho các phương thức của mình, và Spring tạo chúng cho bạn, và bạn chỉ cần nói với anh ấy điều gì đó như “Tôi muốn nuôi một con mèo ở đây” và anh ấy chuyển nó cho bạn theo phương thức của bạn). Chúng ta sẽ thường xuyên gặp điều thứ hai trong các bài viết tiếp theo.

Đậu và bối cảnh

Một trong những khái niệm quan trọng trong mùa xuân là Bean . Về bản chất, nó chỉ là một đối tượng của một lớp nào đó. Giả sử chương trình của chúng ta cần sử dụng 3 đối tượng: một con mèo, một con chó và một con vẹt. Và chúng ta có một loạt các lớp với nhiều phương thức, trong đó đôi khi chúng ta cần một con mèo cho một phương thức và một con chó cho một phương thức khác, và đôi khi chúng ta sẽ có các phương thức mà chúng ta cần một con mèo và một con vẹt (ví dụ: một phương thức để cho mèo ăn, hehe), và trong một số phương pháp, sẽ cần cả ba đồ vật. Có, trước tiên chúng ta có thể tạo ba đối tượng này trong phần chính, sau đó chuyển chúng đến các lớp của chúng ta và từ bên trong lớp đó đến các phương thức mà chúng ta cần... Và cứ thế trong suốt chương trình. Và nếu chúng ta cũng tưởng tượng rằng định kỳ chúng ta muốn thay đổi danh sách các tham số được chấp nhận cho các phương thức của mình (à, chúng ta đã quyết định viết lại một cái gì đó hoặc thêm chức năng) - thì chúng ta sẽ phải thực hiện khá nhiều chỉnh sửa đối với mã nếu cần thay đổi một cái gì đó. Bây giờ, điều gì sẽ xảy ra nếu chúng ta tưởng tượng rằng chúng ta không có 3 mà là 300 đồ vật như vậy? Một cách khác là thu thập tất cả các đối tượng như vậy của chúng ta vào một danh sách chung các đối tượng ( List<Object> ) và chuyển nó cho tất cả các phương thức, và từ bên trong các phương thức sẽ lấy đối tượng này hoặc đối tượng kia mà chúng ta cần. Nhưng điều gì sẽ xảy ra nếu chúng ta tưởng tượng rằng khi chương trình tiến triển, một số đối tượng có thể được thêm vào danh sách này hoặc (điều gì tệ hơn) bị xóa? Sau đó, trong tất cả các phương thức mà chúng ta truy xuất các đối tượng từ danh sách theo chỉ mục của chúng, mọi thứ đều có thể bị hỏng. Sau đó, chúng tôi quyết định lưu trữ không phải danh sách mà là bản đồ, trong đó khóa sẽ là tên của đối tượng chúng tôi cần và giá trị sẽ là chính đối tượng đó, sau đó chúng tôi có thể lấy các đối tượng chúng tôi cần từ nó chỉ bằng tên của chúng : get("parrot") và để đáp lại chúng tôi đã nhận được một đối tượng con vẹt Hoặc ví dụ key là lớp của đối tượng, còn giá trị là chính đối tượng đó thì chúng ta không còn có thể chỉ ra tên đối tượng mà chỉ đơn giản là lớp của đối tượng mình cần, cũng tiện. Hoặc thậm chí viết một số loại trình bao bọc trên bản đồ, nơi bạn có thể tạo các phương thức để trong một số trường hợp, bạn có thể truy xuất các đối tượng theo tên của chúng và trong các trường hợp khác theo lớp. Đây là những gì chúng tôi nhận được từ bối cảnh ứng dụng mùa xuân . Một bối cảnh là một tập hợp các hạt (đối tượng). Chuyển sang ngữ cảnh, chúng ta có thể lấy đậu (đối tượng) mà chúng ta cần theo tên của nó, chẳng hạn như theo loại của nó hoặc theo thứ gì đó khác. Ngoài ra, chúng ta có thể yêu cầu Spring tìm kiếm loại đậu mà chúng ta cần trong ngữ cảnh của nó và chuyển nó vào phương thức của chúng ta. Ví dụ: nếu chúng ta có một phương thức như thế này:

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

Khi Spring gọi phương thức này cho chúng ta, nó đã chuyển đối tượng con mèo của chúng ta từ ngữ cảnh của nó vào đó. Bây giờ chúng tôi quyết định rằng phương pháp của chúng tôi, ngoài một con mèo, còn cần một con vẹt. Sử dụng mùa xuân - không có gì dễ dàng hơn đối với chúng tôi! Chúng tôi chỉ đơn giản viết:

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

và Spring khi nó gọi phương thức này của chúng ta sẽ hiểu là chúng ta cần truyền vào đây một con mèo và một con vẹt, đi tới ngữ cảnh của nó, lấy hai đối tượng này và chuyển chúng vào phương thức của chúng ta. Bằng cách bàn giao quyền điều hành chương trình của chúng tôi cho Spring, chúng tôi cũng chuyển giao cho anh ấy trách nhiệm tạo ra các đối tượng và chuyển chúng sang các phương thức của chúng tôi mà anh ấy sẽ gọi. Câu hỏi đặt ra: làm thế nào Spring biết được đối tượng (thùng) nào cần tạo?

Phương pháp cấu hình ứng dụng

Có ba cách chính để cấu hình một ứng dụng (nghĩa là cho Spring biết chúng ta cần làm việc với đối tượng nào):

1. sử dụng tệp/cấu hình xml;
2. sử dụng cấu hình java;
3. cấu hình tự động.

Các nhà phát triển mùa xuân sắp xếp chúng theo thứ tự ưu tiên sau:

• phương pháp ưu tiên nhất cần được ưu tiên là cấu hình tự động;
• nếu sử dụng cấu hình tự động thì không thể cấu hình chính xác tất cả các Bean có thể, hãy sử dụng cấu hình Java (tạo đối tượng bằng mã Java);
• Chà, cách ưu tiên thấp nhất là cách cũ, sử dụng cấu hình xml.

Ngoài ra Spring còn cho phép bạn kết hợp các phương thức này. Ví dụ, hãy để Spring thực hiện mọi thứ có thể được cấu hình tự động; trong đó bạn cần chỉ định một số tham số đặc biệt, thực hiện bằng cách sử dụng cấu hình Java và ngoài ra, bạn có thể kết nối một số cấu hình kế thừa ở định dạng xml. Nói chung, tất cả điều này có thể được thực hiện khá linh hoạt. Tuy nhiên, nếu mọi thứ có thể được thực hiện bằng cài đặt tự động, hãy sử dụng nó. Tôi sẽ chỉ xem xét cấu hình tự động và cấu hình Java; Các cấu hình xml đã được sử dụng trong hầu hết mọi ví dụ về Spring trên Internet và một khi bạn hiểu cách cấu hình Java hoạt động, sẽ không có vấn đề gì khi “đọc” một tệp xml thực hiện điều tương tự. Cấu hình tự động được sử dụng khi đối tượng chúng ta cần cho công việc là đối tượng của lớp chúng ta đã viết . Nếu cần một số logic rất cụ thể để tạo một đối tượng của lớp của chúng ta hoặc nếu chúng ta không có cơ hội đánh dấu một lớp bằng chú thích mà chúng ta cần, chú thích này sẽ được cấu hình tự động chọn, thì điều này có thể được thực hiện trong cấu hình Java . Trong phần tiếp theo, chúng ta sẽ tạo một dự án maven, kết nối một vài mô-đun lò xo trung tâm với nó và tạo ra những hạt đậu đầu tiên.