Lớp dịch vụ ứng dụng gọi các chức năng cơ sở dữ liệu. Kiến trúc xấu?

Kịch bản:

• Ngăn xếp: Java, Spring, Hibernate.
• Mô hình: Ứng dụng Máy khách-Máy chủ.
• Mẫu: Model-View-Controller (MVC).

Các lớp lớp dịch vụ có ba hành vi:

1. Một số dịch vụ có quy tắc kinh doanh trong các phương thức và ủy thác sự kiên trì cho ứng dụng. Giống:

   EntityManager.save (thực thể);

2. Một số dịch vụ chỉ cần gọi một hàm cơ sở dữ liệu (truyền tham số) Giống như:

   CallableStatement cls = con.prepareCall ("{gọi cơ sở dữ liệu hàm (args)}");

3. Một số dịch vụ có phương pháp với cả hai hành vi.

Những câu hỏi của tôi:

1. Có bất kỳ vấn đề trong việc có các dịch vụ ứng dụng gọi - trực tiếp - chức năng cơ sở dữ liệu? Đây không phải là thực hành xấu? Điều gì sẽ là một mô hình kiến ​​trúc áp dụng cho một dự án như thế này?
2. Có bất kỳ vấn đề trong việc kết hợp hành vi trong cùng một dịch vụ không? Chẳng hạn như giao dịch và tính nhất quán?
3. Trong trường hợp bảo trì, việc đóng gói này có làm cho nhà phát triển mơ hồ rằng anh ta cũng nên thay đổi các chức năng trong cơ sở dữ liệu không? Làm thế nào để tránh điều này?
4. Liệu kịch bản này xảy ra trong các ứng dụng khác trên toàn thế giới hay đó chỉ là một lỗi kiến ​​trúc?

Có bất kỳ vấn đề trong việc có các dịch vụ ứng dụng gọi - trực tiếp - chức năng cơ sở dữ liệu? Đây không phải là thực hành xấu?

Tôi nghĩ có. Bạn đang đặt một kiến ​​thức về các cơ sở dữ liệu bên trong dịch vụ ứng dụng. Thay đổi cơ sở dữ liệu theo bất kỳ cách nào (thay đổi công cụ lưu trữ hoặc thậm chí đổi tên trường hoặc tạo chỉ mục) có thể yêu cầu bạn thay đổi dịch vụ ứng dụng và vi phạm SRP .

Điều gì sẽ là một mô hình kiến ​​trúc áp dụng cho một dự án như thế này?

Xem bình luận dưới đây.

Có bất kỳ vấn đề trong việc kết hợp hành vi trong cùng một dịch vụ không? Chẳng hạn như giao dịch và tính nhất quán?

Tôi không tin rằng có một vấn đề kỹ thuật, nhưng có một vấn đề hợp lý. Bạn chỉ cần trộn hai cách tiếp cận trong ứng dụng làm cho nó mơ hồ, ít cấu trúc, khó thích ứng với các thay đổi. Xem ý kiến ​​trên về việc vi phạm SRP cũng.

Trong trường hợp bảo trì, việc đóng gói này có làm cho nhà phát triển mơ hồ rằng anh ta cũng nên thay đổi các chức năng trong cơ sở dữ liệu không?

Chắc chắn là có.

Làm thế nào để tránh điều này?

Đặt các phương thức và hàm, trực tiếp làm việc với cơ sở dữ liệu vào một mức độ trừu tượng riêng biệt (có thể là lớp DAO hoặc mẫu kho lưu trữ đơn giản - tùy thuộc vào độ phức tạp của ứng dụng của bạn)

Liệu kịch bản này xảy ra trong các ứng dụng khác trên toàn thế giới hay đó chỉ là một lỗi kiến ​​trúc?

Tôi nghĩ trong thế giới của chúng ta mọi thứ xảy ra;)

Theo những gì bạn nói có một lớp dịch vụ nên mô hình kiến ​​trúc có vẻ phù hợp là Layered Architecture. Tham khảo thêm

Vâng, đó thường là một thực tiễn xấu khi thực hiện các cuộc gọi cơ sở dữ liệu trực tiếp trên một lớp khác ngoài lớp truy cập dữ liệu, theo cách đó, lớp nghiệp vụ chỉ truy cập một sự trừu tượng hóa của cơ sở dữ liệu.

Đối với các hành vi trộn, sử dụng một số mẫu thiết kế làm mẫu DAO hoặc mẫu Kho lưu trữ có thể giúp ủy thác các trách nhiệm đó do đó cải thiện mã đó.

Một số ưu điểm của việc sử dụng mẫu thiết kế và ORM là khả năng đọc mã của bạn, việc đóng gói các trách nhiệm vì vậy nếu quyền truy cập cơ sở dữ liệu của bạn thay đổi thì lớp doanh nghiệp của bạn sẽ không thay đổi nhiều.