Lớp dịch vụ so với DAO - Tại sao cả hai?

Tôi đã làm việc với SpringMVC, Hibernate và một số cơ sở dữ liệu trong một ví dụ ứng dụng web java.

Có một vài cái khác nhau thực hiện điều này, nhưng ví dụ về hướng dẫn tích hợp ngủ đông và mùa xuân 3 này có một lớp mô hình, khung nhìn (trong jsp), và một lớp dịch vụ và dao cho bộ điều khiển.

Câu hỏi của tôi là, không phải cả hai lớp dịch vụ và DAO đều làm điều tương tự? Tại sao bạn cần cả hai?

Đây là hướng dẫn tôi thực sự đang sử dụng: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/

Nói chung, DAO càng nhẹ càng tốt và chỉ tồn tại để cung cấp kết nối với DB, đôi khi được trừu tượng hóa để có thể sử dụng các phụ trợ DB khác nhau.

Lớp dịch vụ ở đó để cung cấp logic để vận hành trên dữ liệu được gửi đến và từ DAO và máy khách. Rất thường 2 phần này sẽ được bó lại với nhau trong cùng một mô-đun và đôi khi thành cùng một mã, nhưng bạn vẫn sẽ thấy chúng là các thực thể logic riêng biệt.

Một lý do khác là bảo mật - Nếu bạn cung cấp một lớp dịch vụ không liên quan đến DB, thì việc truy cập DB từ máy khách sẽ khó khăn hơn ngoại trừ thông qua dịch vụ. Nếu DB không thể được truy cập trực tiếp từ máy khách (và không có mô-đun DAO tầm thường nào đóng vai trò là dịch vụ) thì tất cả kẻ tấn công đã chiếm quyền máy khách cũng có thể cố gắng hack lớp dịch vụ trước khi anh ta có được tất cả trừ truy cập vệ sinh nhất vào dữ liệu của bạn.

Tôi là người viết bài trong câu hỏi. Tôi đã có phần chia sẻ công bằng của mình khi làm việc trên các công nghệ khác nhau và các kiến ​​trúc khác nhau. Dựa vào bên trên, tôi có thể nói một cách an toàn rằng có lớp dịch vụ và lớp dao luôn là một ý tưởng tốt. DAO nên được giới hạn chỉ thêm / cập nhật / chèn / chọn các đối tượng Thực thể vào / từ cơ sở dữ liệu và đó là tất cả. Nếu bạn muốn làm bất cứ điều gì thêm về mặt logic, hãy thêm nó vào lớp dịch vụ. Điều này sẽ giúp tạo mã theo mô-đun và dễ dàng thay thế khi cơ sở dữ liệu được thay thế (đối với một phần dữ liệu). Điều này đặc biệt áp dụng trong các ứng dụng liên quan đến các báo cáo có logic nặng ngay cả sau khi tìm nạp dữ liệu từ cơ sở dữ liệu.

Ngoài ra, vào mùa xuân, bảo mật được áp dụng ở lớp dịch vụ lý tưởng. Bạn sẽ không muốn thay đổi theo cách này.

Adam Bien chỉ ra trong cuốn sách của mình một thực tế rằng JPA EntityManager là một triển khai phổ biến tốt của DAO:

http://realworldpotypes.com/

Trong thế giới Java EE, hầu như không bao giờ cần phải viết DAO của riêng bạn vì các triển khai JPA bao gồm một. Bạn chỉ phải viết lớp dịch vụ.

Việc thực hiện lớp DAO của riêng bạn thực sự là một sự nôn nao từ kiến ​​trúc J2EE rất kém của 15 năm trước, nhưng nhiều người vẫn cảm thấy bắt buộc phải làm điều đó. Các lớp DAO tùy chỉnh này thường không cung cấp gì nhiều hơn các hàm chuyển tiếp gọi phương thức tương ứng trên EntityManager.

Vì vậy, để trả lời câu hỏi của bạn, có bạn cần một lớp dịch vụ và DAO, nhưng bạn chỉ phải viết lớp dịch vụ.

Tôi thường đặt tất cả mã db cụ thể (truy vấn) trong DAO và xử lý giao dịch và logic nghiệp vụ trong các dịch vụ. Điều này cho phép các phương thức dịch vụ gọi các phương thức trên nhiều dao và giữ tất cả trong cùng một giao dịch. Theo tôi, điều này cho phép tái sử dụng mã tốt hơn trên dao.

Tôi đã thấy rằng lớp dịch vụ thêm sự phức tạp không cần thiết trong hầu hết các trường hợp. Về lý thuyết là để tránh logic kinh doanh trong lớp dao nhưng cuối cùng, điều này chỉ dẫn đến sự nhầm lẫn, thậm chí một số người đã không đồng ý loại bỏ hoàn toàn lớp dao vì họ cảm thấy nó không thêm giá trị. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-reposeective-abstraction-layer

Nhưng nếu bạn có nhiều logic kinh doanh thì có. Đó là một ý tưởng tốt. Làm thế nào là thiết yếu để làm cho một lớp dịch vụ?

IMHO lớp Dịch vụ có thể được coi là một lớp giữa bộ điều khiển và lớp DAO. Lớp dịch vụ này chính xác là nơi chúng ta có thể thêm logic nghiệp vụ và thậm chí tạo một đối tượng trả về cụ thể cho những gì cần được hiển thị bởi khung nhìn.