Làm thế nào là thiết yếu để làm cho một lớp dịch vụ?

Tôi bắt đầu xây dựng một ứng dụng gồm 3 lớp (DAL, BL, UI) [nó chủ yếu xử lý CRM, một số báo cáo bán hàng và hàng tồn kho].

Một đồng nghiệp nói với tôi rằng tôi phải chuyển sang mẫu lớp dịch vụ, rằng các nhà phát triển đã đến với mẫu dịch vụ từ kinh nghiệm của họ và đó là cách tiếp cận tốt hơn để thiết kế hầu hết các ứng dụng. Ông nói rằng sẽ dễ dàng hơn nhiều để duy trì ứng dụng trong tương lai theo cách đó.

Cá nhân, tôi có cảm giác rằng nó chỉ khiến mọi thứ trở nên phức tạp hơn và tôi không thể thấy được nhiều lợi ích từ nó sẽ chứng minh điều đó.

Ứng dụng này có thêm một phần nhỏ ui sử dụng một số (nhưng chỉ một vài) chức năng của ứng dụng máy tính để bàn nên tôi đã thấy mình sao chép một số mã (nhưng không nhiều). Chỉ vì một số sao chép mã, tôi sẽ không chuyển đổi nó thành định hướng dịch vụ, nhưng anh ấy nói tôi nên sử dụng nó vì dù sao nó là một kiến ​​trúc rất tốt, tại sao các lập trình viên lại rất đam mê dịch vụ ??

Tôi đã cố gắng google trên đó nhưng tôi vẫn bối rối và không thể quyết định phải làm gì.

Cuốn sách "Các mô hình kiến ​​trúc doanh nghiệp" của Martin Fowler nói:

Câu hỏi dễ trả lời hơn có lẽ là khi không sử dụng nó. Bạn có thể không cần Lớp dịch vụ nếu logic nghiệp vụ của ứng dụng của bạn sẽ chỉ có một loại khách hàng - giả sử, giao diện người dùng - và đó là phản hồi trường hợp sử dụng không liên quan đến nhiều tài nguyên giao dịch. [...]

Nhưng ngay khi bạn hình dung ra một loại khách hàng thứ hai hoặc tài nguyên giao dịch thứ hai trong các phản ứng trong trường hợp sử dụng, nó sẽ trả tiền để thiết kế trong Lớp dịch vụ ngay từ đầu.

Lợi ích mà Lớp dịch vụ cung cấp là nó xác định một tập hợp các hoạt động ứng dụng phổ biến có sẵn cho các máy khách khác nhau và điều phối phản hồi trong mỗi hoạt động. Khi bạn có một ứng dụng có nhiều loại khách hàng sử dụng logic kinh doanh của nó và có các trường hợp sử dụng phức tạp liên quan đến nhiều tài nguyên giao dịch - sẽ rất hợp lý khi bao gồm Lớp dịch vụ với các giao dịch được quản lý.

Với CRM, Bán hàng và Hàng tồn kho sẽ có rất nhiều trường hợp sử dụng kiểu CRUD trong đó hầu như luôn luôn có sự tương ứng một-một với các hoạt động của Lớp dịch vụ. Các phản hồi về việc tạo, cập nhật hoặc xóa đối tượng miền cần được phối hợp và giao dịch nguyên tử bằng các hoạt động của Lớp dịch vụ.

Một lợi ích khác của việc có Lớp dịch vụ là nó có thể được thiết kế cho lệnh gọi cục bộ hoặc từ xa hoặc cả hai - và cho phép bạn linh hoạt để làm điều đó. Mẫu này đặt nền tảng cho việc triển khai đóng gói logic nghiệp vụ của ứng dụng và gọi logic đó bởi các khách hàng khác nhau một cách nhất quán. Điều này có nghĩa là bạn cũng giảm / loại bỏ mã trùng lặp, vì khách hàng của bạn chia sẻ cùng các dịch vụ phổ biến. Bạn cũng có khả năng giảm chi phí bảo trì - vì khi logic kinh doanh của bạn thay đổi, bạn (nói chung) chỉ cần thay đổi dịch vụ chứ không phải mỗi khách hàng.

Tóm lại, thật tốt khi sử dụng Lớp dịch vụ - hơn nữa tôi nghĩ trong ví dụ của bạn, bạn đã cung cấp vì có vẻ như bạn có nhiều khách hàng logic kinh doanh.

Thêm một lớp dịch vụ bởi vì bạn đã đánh giá ý tưởng và kết luận cách tiếp cận tốt nhất của nó: tốt

Thêm một lớp dịch vụ vì đó là điều mà tất cả những đứa trẻ tuyệt vời đang làm: xấu

Nếu ruột của bạn nói rằng bạn không cần một cái, thì đừng tạo ra nó.

Một trong những phát triển đáng thất vọng hơn trong thế giới lập trình trong hơn 10 năm qua là nó đã trở thành định hướng "thời trang" khó chịu, với những người theo xu hướng và băng đô như thể chúng là giày mùa này. Đừng rơi vào cái bẫy đó. Bởi vì mùa tới 'mọi người' sẽ nói với bạn rằng bạn nên thiết kế nó theo một cách khác.

Không có gì sai hoặc đúng với một lớp dịch vụ - đó là một cách tiếp cận cụ thể mà sự phù hợp của nó cần được đánh giá dựa trên giá trị kỹ thuật của nó cho dự án. Đừng cảm thấy bắt buộc phải thay thế ý kiến ​​của người khác cho phán đoán của riêng bạn.

Có nhiều yếu tố đi vào quyết định tạo ra một lớp dịch vụ. Tôi đã tạo các lớp dịch vụ trong quá khứ vì những lý do sau.

1. Mã cần được sử dụng lại bởi nhiều khách hàng.
2. Thư viện bên thứ ba mà chúng tôi có giấy phép hạn chế.
3. Các bên thứ ba cần một điểm tích hợp vào hệ thống của chúng tôi.
4. Tập trung logic kinh doanh trùng lặp.

Trường hợp 1: Bạn đang tạo chức năng cơ bản cần được sử dụng bởi vô số khách hàng khác nhau. Lớp dịch vụ tích hợp chức năng cho các khách hàng khác nhau để khai thác chức năng được cung cấp của bạn ngay lập tức.

Trường hợp 2: Bạn thường lưu trữ mã trong không gian ứng dụng nhưng bạn đang sử dụng thư viện của bên thứ ba mà bạn có giấy phép hạn chế. Trong trường hợp này, bạn có một tài nguyên bạn muốn sử dụng ở mọi nơi, nhưng chỉ có một số lượng hạn chế. Nếu bạn lưu trữ nó phía sau một dịch vụ thì toàn bộ tổ chức của bạn có thể sử dụng dịch vụ đó từ các ứng dụng của họ mà không phải mua giấy phép cho mỗi lưu trữ riêng lẻ.

Trường hợp 3: Bạn đang xây dựng chức năng cho bên thứ ba liên lạc với bạn. Trong ví dụ của bạn, bạn có thể thiết lập điểm cuối hàng tồn kho để cho phép các nhà cung cấp chuyển tin nhắn cho bạn về các lô hàng sản phẩm đến.

Trường hợp 4: Bạn đã phân tích toàn bộ doanh nghiệp mã của mình và thấy rằng các nhóm riêng biệt đã tạo ra cùng một thứ (chỉ được thực hiện hơi khác nhau). Với lớp dịch vụ, bạn có thể chọn (các) phương pháp tốt nhất và bây giờ bạn có thể thực hiện quy trình tương tự trên tất cả các nhóm bằng cách yêu cầu họ gọi vào dịch vụ. Một lợi ích khác để tập trung logic là khi tìm thấy lỗi. Bây giờ bạn có thể triển khai sửa lỗi một lần và tất cả khách hàng được hưởng lợi ích cùng một lúc.

Tất cả điều này đang được nói có những tiêu cực tiềm năng cho một lớp dịch vụ.

1. Thêm sự phức tạp của hệ thống. Trường hợp trước đây bạn chỉ có một ứng dụng để gỡ lỗi thì bây giờ bạn có hai ứng dụng. Sự cố sản xuất yêu cầu kiểm tra cài đặt ứng dụng khách, cài đặt ứng dụng dịch vụ hoặc sự cố giao tiếp giữa các ứng dụng máy khách và máy chủ được thiết lập chính xác. Điều này có thể khó khăn nếu bạn chưa bao giờ làm điều đó trước đây.
2. Một điểm thất bại. Nếu bạn bị mất dịch vụ, tất cả khách hàng đều bị ảnh hưởng. Khi mã không được triển khai theo cách này, rủi ro có thể ít hơn (mặc dù có nhiều cách để giảm thiểu điều này).
3. Phiên bản có thể khó hơn để làm. Khi bạn có một ứng dụng sử dụng dịch vụ triển khai thay đổi giao diện có thể được thực hiện cùng một lúc giữa hai ứng dụng. Khi bạn có nhiều khách hàng, bạn phải quản lý ai là người trên V1, người đang ở V2 và điều phối việc loại bỏ V1 (khi bạn biết mọi người đã cập nhật lên V2).

Điểm chính là nó không phải lúc nào cũng là một cú hích để làm cho dịch vụ hệ thống của bạn được định hướng. Theo kinh nghiệm của tôi, đó thường là một ý tưởng tốt (tôi có xu hướng cấu trúc các ứng dụng theo cách này), nhưng đó không phải là một quyết định tự động. Vào cuối ngày, bạn cần cân nhắc những ưu và nhược điểm và đưa ra quyết định phù hợp với tình huống của mình.

Hầu hết các lớp dịch vụ tôi đã thấy là một mớ hỗn độn. Các dịch vụ có xu hướng có rất nhiều phương pháp khác nhau, 1500 LỘC không phải là hiếm. Các phương thức khác nhau không có gì chung, nhưng hãy chia sẻ mã. Điều này dẫn đến khớp nối cao , độ kết dính thấp . Nó cũng vi phạm OCP , vì mỗi khi cần một thao tác mới, bạn phải sửa đổi mã thay vì mở rộng cơ sở mã. Một lớp dịch vụ được xây dựng tốt về mặt lý thuyết là có thể, nhưng tôi chưa bao giờ thấy nó trong thực tế.

CQRS giải quyết những vấn đề này và ngăn bạn khỏi phải tạo một trong những lớp dịch vụ thủ tục đó.

Thêm một giao diện (một lớp dịch vụ là một loại giao diện) cần có thời gian. Một cái tốt cần rất nhiều thời gian để thiết kế và thử nghiệm. Điều rất quan trọng để có được nó ngay lần thử đầu tiên bởi vì việc thay đổi nó sau đó sẽ phá vỡ tất cả các khách hàng. Ngoài ra, hãy xem xét rằng bạn có thể sẽ không biết những gì cần có trong giao diện đó cho đến khi bạn có một khách hàng thứ hai với các nhu cầu hơi khác nhau. Duy trì một dịch vụ là một dự án không bao giờ kết thúc.

Trong hầu hết các tổ chức, nếu bạn đến nhà tài trợ kinh doanh của mình và hỏi họ: "Bạn có muốn các bộ phận khác nhận được lợi ích (tái sử dụng) hệ thống này mà chúng tôi đang phát triển với ngân sách của bạn không?" họ sẽ cười bạn Làm cho nó hoạt động cho nhà tài trợ doanh nghiệp của bạn trước, sau đó bắt đầu xoay vòng với việc sử dụng lại mã đó (vào thời gian riêng của bộ phận của bạn).

Nếu bạn biết, thực tế, chức năng bạn đang viết hôm nay sẽ được sử dụng lại bởi nhiều khách hàng dịch vụ khác nhau, sau đó xem xét thiết kế một lớp dịch vụ ngay từ ngày đầu. Nếu bạn không chắc chắn, hoặc có nhiều ẩn số trong dự án, hãy lấy thứ gì đó đơn giản làm việc trước và tách nó thành dịch vụ và máy khách sau nếu bạn có thời gian và ngân sách. Dễ dàng hơn nhiều để có được giao diện dịch vụ ngay lần thử đầu tiên khi bạn bắt đầu với một hệ thống làm việc.

Tái bút: Nếu bạn đang làm việc trong Java, Joshua Bloch có rất nhiều lời khuyên về giao diện tuyệt vời trong suốt cuốn sách của mình, Java hiệu quả.

Tôi đồng ý với bạn. Không cần thêm một lớp nữa nếu bạn đang sử dụng một UI.

DAL, BL và UI / Bộ điều khiển là sự kết hợp tốt để thiết kế một ứng dụng. Nếu bạn đang dự định đi với một giao diện người dùng duy nhất, không cần phải chuẩn bị thêm một lớp. Bao gồm thêm 1 lớp vào ứng dụng chỉ làm tăng nỗ lực / thời gian phát triển.

Một schenerio khác là sử dụng nhiều UI trong ứng dụng của bạn, thật tốt khi có một lớp dịch vụ để xử lý UI trong trường hợp này.

Stack Overflow: Thảo luận về mẫu lớp dịch vụ

Tôi sẽ tranh luận rằng BL của bạn là lớp dịch vụ của bạn. Một nơi trung tâm nơi logic kinh doanh của bạn ngồi. Đây phải là một DLL có thể được sử dụng bởi bất cứ thứ gì cần logic đó. Sau đó, bạn có thể đặt một lớp api web lên trên đó nếu ứng dụng của bạn sẽ có các giao diện người dùng khác nhau.