Cấu trúc dịch vụ RESTful với Java Spring cho người mới bắt đầu


12

Tôi còn khá mới về các kỹ năng phát triển web Java. Tôi có một dự án mà tôi nghĩ sẽ tạo ra một ứng cử viên tốt cho dịch vụ RESTful từ những gì tôi hiểu về API. Tôi đang cố gắng tìm hiểu chi tiết về cách thức này được cấu trúc, nhưng không thực sự đi đến đâu về mặt tìm kiếm google và đọc tài liệu tôi đã có. Tôi hy vọng rằng bài đăng này sẽ mang lại một số xác nhận và / hoặc chuyển hướng về kiến ​​thức và giả định của tôi về chủ đề này.

Giả định hiện tại của tôi là dịch vụ RESTful của tôi sẽ có cấu trúc như sau:

  • Dữ liệu cơ sở dữ liệu (SQL).
  • Một ORM (Tôi đang sử dụng một ORM tương đối phổ biến được gọi là CPO, nhưng điều này sẽ chỉ được thay thế bằng Hibernate với hầu hết mọi người).
  • Một lớp trình quản lý Java với các phương thức nói chuyện với ORM để lấy dữ liệu
  • Một lớp / lớp của trình điều khiển Java xử lý ánh xạ yêu cầu và sử dụng @ResponseBodyđể chỉ đạo / xử lý URL và các hành động về cách xử lý dữ liệu thông qua các động từ HTTP ( http://mysite.com/computers/dell có thể được GETyêu cầu bằng từ "dell" trong URL là một tham số sẽ trả về một mảng thông tin JSON về máy tính dell).
  • Dịch vụ này nên được thực hiện với Spring Boot, hoặc bằng cách nào đó có thể độc lập và độc lập với bất kỳ ứng dụng nào khác.

Bây giờ giả sử rằng những điều trên là chính xác, thì tôi sẽ có (ở mức độ rất cơ bản) một dịch vụ RESTful mà bất kỳ ứng dụng nào cũng có thể sử dụng để sử dụng và sử dụng dữ liệu.

Vì vậy, nói rằng tôi có ứng dụng web của tôi. Giả sử tôi đang tạo một ứng dụng web về thông tin phần cứng máy tính và tôi đang sử dụng Spring để xây dựng ứng dụng web này. Dưới đây là những giả định của tôi:

  • Tôi có một loạt các khung nhìn dưới dạng các tệp JSP, với các tệp JSP có HTML, CSS và JavaScript bao gồm. JavaScript sẽ xử lý các cuộc gọi AJAX đến bộ điều khiển của ứng dụng này khi cần (bên dưới).
  • Ứng dụng web này cũng sẽ có bộ điều khiển riêng để xử lý các yêu cầu và định tuyến URL của ứng dụng và sau đó, bộ điều khiển sẽ sử dụng ModelAndViewđối tượng hoặc thứ gì đó dọc theo các dòng đó để "nói chuyện" với bộ điều khiển của dịch vụ RESTful, lấy bất kỳ dữ liệu nào được truyền qua , chuyển dữ liệu đó trở lại chế độ xem (Javascript, JSP, v.v.) để hiển thị.

Tôi có đang đi đúng hướng không? Tôi hiểu rằng cũng có một khía cạnh xác thực cho các dịch vụ RESTful, nhưng tôi chưa có khái niệm đó (và dự án của tôi sẽ được sử dụng trong một mạng riêng vì vậy bảo mật không phải là ưu tiên tại thời điểm này).

Bất kỳ cái nhìn sâu sắc, phê bình, kiến ​​thức, thông tin phản hồi, hoặc làm rõ được đánh giá rất cao.

Câu trả lời:


19

Đây là một trong những ví dụ yêu thích về cấu trúc cho ứng dụng nghỉ xuân của bạn.

1. Tách các lớp, mỗi lớp là một mô-đun / dự án riêng

  • API REST
    • Đóng gói dưới dạng chiến tranh (Có thể là jar nếu bạn đang sử dụng spring boot với máy chủ nhúng. Spring boot doc giải thích rõ ràng cách triển khai cái gọi là uber jar . Thật đơn giản chết người.)
    • Nó có bộ điều khiển nghỉ ngơi xử lý yêu cầu / phản hồi
    • phụ thuộc vào Module dịch vụ bên dưới
  • Dịch vụ
    • Đóng gói như bình
    • Trừu tượng logic kinh doanh, lớp này không có ý tưởng làm thế nào để giao tiếp với nguồn dữ liệu.
    • Nó sẽ được autowired trong bộ điều khiển phần còn lại
    • Phụ thuộc vào mô đun DAO / Kho lưu trữ bên dưới
  • DAO / Kho lưu trữ
    • Đóng gói như bình
    • Nói chuyện với nguồn dữ liệu trực tiếp, có các hoạt động thường được gọi là CRUD. Nó có thể là jdbc, JPA hoặc thậm chí truy cập tệp đơn giản.
    • Phụ thuộc vào mô-đun miền bên dưới
  • Miền
    • Đóng gói như bình
    • Nó có các mô hình miền của bạn, thường là các lớp POJO. Nếu bạn đang sử dụng ORM, chúng là các thực thể ORM.
    • Nó cũng có thể có DTO (Đối tượng truyền dữ liệu), vẫn đang được tranh luận sôi nổi. Sử dụng nó hay không là cuộc gọi của bạn.
  • Bạn có thể thêm nhiều mô-đun như tiện ích, tích hợp bên thứ ba, v.v. nhưng những điều trên rất được khuyến khích nên có.

2. Công cụ quản lý xây dựng / phụ thuộc (IMHO rất cần thiết)

Có rất nhiều trong số họ, tìm kiếm google sẽ cho bạn thấy. Cá nhân tôi thích Maven với Spring. Nó chỉ đơn giản là làm việc cho cấu trúc dự án trên.
Cũng lưu ý rằng nếu bạn đang sử dụng maven, có một mô đun mẹ tổng hợp tất cả các mô-đun được thảo luận trong phần 1. Tất cả các mô-đun điểm đạn cũng tương ứng với các mô-đun maven.

3. Suy nghĩ về dự án cụ thể của bạn

Vì bạn đang sử dụng REST, tôi thực sự khuyên bạn KHÔNG nên sử dụng JSP làm quan điểm của mình. Bạn có thể sử dụng HTML5 + Javascript đơn giản hoặc một số khung phổ biến như AngularJS làm chế độ xem của bạn.
Nếu bạn khăng khăng sử dụng JSP, bạn sẽ cần phải giới thiệu một cuộc chiến khác (ứng dụng web) có bộ điều khiển và tệp JSP. Trình điều khiển sẽ lấy dữ liệu (thường là định dạng Json / xml) và sau đó phân tích chúng theo các mô hình của bạn (POJO) để JSP của bạn có thể lấy chúng từ trình điều khiển của bạn và hiển thị. Đăng dữ liệu từ JSP là ngược lại, tôi đã bỏ qua ở đây.

Không có hướng dẫn đầy đủ vì chủ đề này khá lớn và phụ thuộc nhiều vào yêu cầu cụ thể của bạn nhưng các điều khoản bao gồm ở đây là đủ để bạn thực hiện nghiên cứu bổ sung (Google, nó là). Hy vọng điều này sẽ cung cấp cho bạn một số ý tưởng về cách tiếp cận.


1
Tên miền thường là lớp chứa logic kinh doanh. Tên miền thường được gọi là lớp chứa các dịch vụ. Các đối tượng miền không phải là POJO đơn giản, Đối tượng miền phải chứa logic nghiệp vụ như xác thực đối số và như vậy. Có lẽ tốt hơn là đổi tên lớp thành một cái gì đó khác. Lớp lưu trữ cũng thường được sử dụng để chuyển dữ liệu từ nhiều nguồn sang các đối tượng miền của bạn.
Andy

Các mô-đun Dịch vụ và Kho lưu trữ cũng sẽ là các dự án Mùa xuân?
Glenn Van Schil

1
@GlennVanSchil Không, đó không phải là các dự án Spring b / c khi toàn bộ dự án được xây dựng, lớp repo / dịch vụ sẽ được bao gồm trong đường dẫn lớp. Kết quả @Autowiresẽ làm việc.
Min Quân Yu

@MinjunYu Cảm ơn câu trả lời rõ ràng! Nhưng repo / dịch vụ của bạn không cần mùa xuân như phụ thuộc maven cho các chú thích Dịch vụ, Kho lưu trữ hoặc Thành phần phải không?
Glenn Van Schil

1
@GlennVanSchil Nếu bạn đặt tất cả các phụ thuộc maven mùa xuân trong pom.xml của mô đun mẹ, thì không cần thêm bất kỳ phụ thuộc liên quan đến mùa xuân nào trong các mô đun con (mô đun repo / dịch vụ). Đây chỉ là một cách để bố trí các dự án nhiều mô-đun vào mùa xuân. Mục đích là để tổ chức mã của bạn. Nếu dự án của bạn không lớn và sẽ không thay đổi trong tương lai gần, bạn có thể kết hợp tên miền, repo, dịch vụ trong cùng một mô-đun gọi là "lõi". Nó trông còn sạch sẽ hơn.
Min Quân Yu

2

Trong khi đồng ý với hầu hết câu trả lời từ @ Minjun.Y, tôi nghĩ rằng tôi sẽ thực hiện một cách tiếp cận hơi khác với lớp trang REST và Web. Từ việc đọc câu hỏi của bạn, tôi nghĩ rằng bạn muốn đưa cả giao diện web và giao diện REST ra thế giới bên ngoài. Có rất ít để có được bằng cách đọc POJO từ cơ sở dữ liệu, biến dữ liệu thành JSON, sau đó quay lại thành POJO để sử dụng bởi các tệp JSP.

Tôi sẽ ưu tiên làm cho lớp dịch vụ thực hiện tất cả công việc thực tế và thêm các lớp "trình bày" riêng biệt cho ứng dụng web (JSP) và bộ điều khiển REST. Đây sẽ là các bộ điều khiển riêng biệt, trong đó dịch vụ sẽ được đưa vào. Ngoài ra, chỉ đi với một dịch vụ REST và xây dựng tất cả logic trình bày ở phía máy khách theo câu trả lời trước đó.

Ngoài ra, tôi không phải là một fan hâm mộ lớn của các mô-đun Maven. Cách cửa hàng Java của chúng tôi triển khai dự án của bạn là tạo các bản phát hành thường xuyên của lớp dịch vụ, sau đó làm cho các lớp trình bày phụ thuộc vào bản phát hành mới nhất. Có chỗ để thảo luận về điều này, nhưng nó chắc chắn hoạt động với chúng tôi. Chúng ta sẽ có giao diện web và giao diện REST như các dự án Maven riêng biệt, vì chúng thường sống trong các tệp .war khác nhau và do đó yêu cầu triển khai riêng.

BTW, tôi sẽ củng cố sự cần thiết phải tăng tốc với các công cụ quản lý xây dựng và phụ thuộc. Một khi dự án của bạn phát triển đến bất kỳ kích thước hợp lý, bạn cần chúng. Các công cụ miễn phí như Maven, Jenkins và Nexus giúp quản lý phát hành ít gặp sự cố hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.