Nơi đặt logic kinh doanh như vậy? Dịch vụ vs DAO?

Question

Được cung cấp:

1. Spring MVC - Hibernate.
2. Bộ điều khiển -> Dịch vụ -> DAO
3. Bây giờ tôi có phương thức lấy thứ gì đó từ DB và EVERYTIME nó thực hiện điều này, phải thực hiện một phương thức khác là "processList" (giống như thay đổi một số giá trị trong danh sách trên một số thông số màn hình).

Câu hỏi:

1. lớp gì để tôi đặt này "processlist"? (Điều khiển, Dịch vụ hoặc DAO? Và tại sao)

Tôi thực sự cần một số giải thích j2ee bây giờ, tôi biết rằng MVC giống nhau trên các ngôn ngữ nhưng tôi chỉ cần chắc chắn :) Nếu tôi làm điều này trong .net Tôi chắc chắn sẽ đưa nó vào phục vụ.

Answer 1

Điều này thực sự phụ thuộc vào những gì processList đang thực hiện chính xác. Không có quy tắc vàng. Một số quy tắc mà tôi cố gắng tuân theo là:

1. Không bao giờ thực hiện cuộc gọi giữa các đối tượng chính trên cùng một lớp.
   • ManagementServiceImpl không bao giờ được gọi NotificationServiceImpl.
2. Không tạo phụ thuộc vòng tròn giữa các đối tượng.
   • Điều này rất giống với hình trên.
3. Nếu bạn thấy mình lặp đi lặp lại một số logic trên nhiều đối tượng chính, cố gắng tái cấu trúc mã và giải nén nó trong lớp logic chuyên (điều này sẽ cải thiện unit-testing cũng).
   • Ví dụ: UserUpdateHandler hoặc NotificationDispatcher (những vẫn được sở hữu bởi các lớp dịch vụ -> không ai khác được phép gọi cho họ) ...
4. Đặt mã nơi nó một cách logic thuộc.
   • Đừng bị phân tâm bởi thực tế, rằng một số lớp cần làm điều gì đó. Nó có thể không phải là nơi thích hợp cho mã.
5. Không bao giờ viết mã được tổng quát hoàn toàn trước khi bạn cần.
   • này có hạn của nó như khái quát non, đó là một thực tế xấu tương tự như sớm tối ưu hóa. Tiết kiệm vài dòng mã bây giờ có thể dẫn đến việc kéo tóc của bạn ra trong tương lai.
6. Luôn viết mã có thể được khái quát hóa.
   • Đây không phải là mâu thuẫn với trước đó. Điều này nói - luôn luôn viết với khái quát hóa trong tâm trí, tuy nhiên không bận tâm với văn bản nếu nó không cần thiết. Hãy suy nghĩ trước, nhưng không nhất thiết phải hành động trước.
7. Rời khỏi logic nghiệp vụ với lớp dịch vụ, logic lưu giữ dữ liệu đến lớp dữ liệu và logic tương tác người dùng với lớp trình bày.
   • Đừng cố gắng phân tích cú pháp đầu vào của người dùng trong lớp dịch vụ. Điều này không thuộc về tương tự như việc tính giá cuối cùng trong ứng dụng e-shop không thuộc về lớp trình bày.

---

Một số ví dụ cho processList:

• Ví dụ tôi - lấy mối quan hệ thêm qua Hibernate#initialize
  • Đây là một cái gì đó thực sự là ở giữa các lớp dịch vụ và DAO . Trên các dự án cũ, chúng tôi đã có lớp chuyên biệt FetchHandler (thuộc sở hữu của lớp dịch vụ). Trong các dự án mới hơn, chúng tôi để điều này hoàn toàn với DAO.
• Ví dụ II - đi qua danh sách và thêm xác nhận kinh doanh tin nhắn đến kết quả
  • lớp dịch vụ, không có nghi ngờ
• Ví dụ III - đi qua danh sách và chuẩn bị Tin nhắn giao diện người dùng dựa trên các lỗi xác thực
  • lớp trình bày

---

Side lưu ý:

• MVC là một điều khác biệt so với kiến ​​trúc ba lớp.
• M mô hình trải rộng trên cả ba lớp. Lớp bản trình bày bao gồm cả hai chế độ xem V và C bộ điều khiển.