Tách dịch vụ -> Đối tượng kinh doanh?

Question

Tôi tin rằng tôi cấu trúc các dự án của mình giống như nhiều người làm. Bạn có một lớp dữ liệu (DAO's), lớp dịch vụ (dịch vụ) và lớp trình bày (Spring MVC, Wicket, ...).

Thông thường dịch vụ bắt đầu khá đơn giản và 'ngắn'. Dần dần, dịch vụ phải hỗ trợ ngày càng nhiều trường hợp sử dụng cho đến sau một thời gian nó trở thành một lớp lớn với nhiều dòng và phương thức và khó đọc và duy trì. Vào thời điểm đó bạn có thể quyết định gắn bó với nó hoặc bắt đầu tái cấu trúc đó là một công việc cồng kềnh và 'nguy hiểm' có thể mất nhiều công sức.

Tôi đang tìm một giải pháp về cách ngăn chặn sự cần thiết cho việc tái cấu trúc trong tương lai.
Một cách tiếp cận có thể chia nhỏ các dịch vụ của bạn trong một số dịch vụ phụ và làm cho dịch vụ ban đầu của bạn trở thành mặt tiền dịch vụ. Vì vậy, ví dụ, thay vì một UserService lớn, bạn có thể có một UserServiceFacade mà đại biểu các cuộc gọi đến PasswordService, RegistrationService, ....

Nó không phải là một giải pháp xấu tôi nghĩ nhưng tôi không quá nhiệt tình về nó bởi vì:

1. khó khăn để xác định trước trong đó subservices chia công việc; nếu bạn missjudged, bạn vẫn có thể cần te aftwards Refactor hoặc có một dịch vụ chỉ với một phương pháp ví dụ
2. tái sử dụng Logic kinh doanh có thể khó khăn hơn nếu ví dụ PasswordService và RegistrationService yêu cầu chức năng chung

giải pháp khác có thể được sử dụng đối tượng kinh doanh mà (trong sự hiểu biết của tôi) cũng có thể được nhìn thấy một subservices nhưng sau đó một cho mỗi UseCase cụ thể, vì vậy bạn có thể có BO như CreateUserBO, CheckPasswordBO, DeleteUserBO, ....

tôi nhiệt tình hơn một chút về cách tiếp cận này bởi vì, trong opnion của tôi, nó cung cấp khá nhiều ưu điểm:

1. BO chính nó là rất có thể đọc được và chỉ thực hiện với nó là hợp đồng đòi hỏi nó để làm; tất cả các phần còn lại có thể được giao cho khác BO, một BO đơn sẽ ngắn và đến điểm
2. Dễ dàng để tái sử dụng chức năng
3. dễ dàng hơn để thay đổi/chuyển thi hành một Usecase nhất định: chỉ cần tiêm thực hiện khác với mùa xuân
4. dễ dàng hơn để kiểm tra: chỉ cần kiểm tra để Usecase cụ thể, các đoàn đến khác BO có thể được chế giễu
5. Cộng tác: ít xung đột nếu số nhà phát triển làm việc trên khác nhau BO của sau đó khi họ làm việc trên cùng một dịch vụ

tôi làm tuy nhiên cũng thấy một số nhược điểm có thể xảy ra:

1. một chút thêm công việc (trong tương lai loại ít nhất) Nhiều hơn nữa
2. lớp mà có thể làm giảm khả năng đọc của dự án của bạn?
3. lớp thêm một trừu tượng: thêm một bước là cần thiết để tìm việc thực hiện thực tế của một Usecase

Câu hỏi hay đúng hơn là câu hỏi (xin lỗi) là:

1. Are Business Objects giải pháp lý tưởng cho vấn đề này?
2. Bạn có đồng ý với những ưu điểm/nhược điểm của BO mà tôi liệt kê ở trên và/hoặc bạn có thấy khác không?
3. Có các giải pháp nào khác (tốt) để ngăn chặn các dịch vụ lớn làm hỏng ngày của bạn không?

Answer 1

Với cách tiếp cận đầu tiên bạn đề cập, thay vì tạo 'mặt tiền', tại sao không chỉ mở rộng dịch vụ đó? Trong tình huống đó, bạn có thể sử dụng lại mã từ lớp siêu/gốc.

Tôi nghĩ nếu một tổ chức cấu trúc gói theo kiểu dễ đọc thì có thể có một số lớp nhỏ hơn trong mọi trường hợp có các lớp lớn đảm nhận nhiều chức năng và có nhiều nguy cơ thay đổi hơn . Cuối cùng tôi nghĩ rằng cả hai cách tiếp cận là khá giống nhau, với một trong hai bạn có thể kết thúc với một mức độ sử dụng lại mã cao, và nếu bạn cần cập nhật cấu trúc nào đó, thì khá dễ dàng để thay đổi toàn cầu (tương đối) nói) và cũng dễ dàng thực hiện các thay đổi triển khai cụ thể.

Answer 2

Điều mà tôi thường làm là tôi luôn sử dụng mặt tiền cho các dịch vụ của mình. Logic nằm trong các lớp bên trong của dịch vụ, nhưng tôi cung cấp một giao diện mà máy khách của dịch vụ đó có thể gọi.

Tôi cố gắng tránh ngay từ đầu để đặt bất kỳ logic nào vào mặt tiền. Nó chỉ là mã tấm nồi hơi chuyển hướng đến logic mã thích hợp.

Vì vậy, ngay cả khi dịch vụ của bạn có nhiều tính năng, mặt tiền là khá dễ bảo trì.

Nhưng nếu bạn kiểm soát toàn bộ cơ sở nguồn, bạn không nên ngần ngại tái cấu trúc và chia nhỏ nếu bạn bắt đầu có quá nhiều tính năng trong một dịch vụ. Ngay cả khi bạn sử dụng một số lớp học để thực hiện công việc, việc tách riêng dịch vụ của bạn sẽ tốt hơn trong thời gian dài.

Answer 3

Tôi khuyên bạn nên xem bài viết này trên Domain Driven Design nếu đơn đăng ký của bạn là bất kỳ điều gì nghiêm trọng hơn việc chuyển nhượng đại học. Tiền đề cơ bản là cấu trúc mọi thứ xung quanh các thực thể của bạn và có một mô hình miền mạnh. Phân biệt giữa các dịch vụ cung cấp những thứ liên quan đến cơ sở hạ tầng (như gửi email, lưu trữ dữ liệu) và các dịch vụ thực sự làm những việc là yêu cầu kinh doanh cốt lõi của bạn.

Tôi cũng xin đề nghị để khám phá Spring Roo - đó mang lại một số nội dung mang tính cách mạng trong xa như strcuturing lớp bạn đang quan tâm như không phải cần DAO layers vv

Hy vọng rằng sẽ giúp.