2011-01-26 39 views
5

Tôi đang cố gắng đánh giá lại kiến ​​trúc lớp n của chúng tôi và muốn nhận một số đề xuất dựa trên trải nghiệm của bạn. Đây là thiết kế .NET n-layer (đôi khi n-tier) điển hình của chúng tôi.thiết kế lớp kinh doanh/dịch vụ lớp n lớp

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

DataAccess thường bao gồm các lớp Entity Framework 4Repository. Tôi cố gắng tuân theo khái niệm Aggregate Root để tránh có một kho lưu trữ cho bảng, nói dễ hơn làm theo kinh nghiệm của tôi. Tôi có xu hướng có ~ 70% kết hợp giữa kho và bảng.

Mẫu thường bao gồm các đối tượng Entity Framework 4 của tôi, tôi đã sử dụng các thực thể Tự theo dõi EF với thành công.

Kinh doanh là điều tôi đấu tranh nhiều nhất. Tôi thường có một lớp học Manager cho mỗi Repository. Lớp này sẽ chứa các phương thức như .Add() sẽ thực hiện xác nhận hợp lệ kinh doanh trước khi chuyển tiếp xuống repository.Add().

Dịch vụ, thông thường tôi sẽ chỉ thực hiện điều này nếu trên thực tế tôi đang tìm cách tạo giải pháp dựa trên dịch vụ web. Lớp này sẽ được giao nhiệm vụ với các yêu cầu/phản hồi giữa các DTO và các thực thể. Và quan trọng nhất là cung cấp thêm giao diện coarse grained. Ví dụ một TradingService.SubmitTrade(), mà thực sự là một facade là cho một giao dịch kinh doanh mà có thể bao gồm AccountManager.ValidateCash(), OrderManager.SubmitOrder(), vv

Mối quan tâm
lớp kinh doanh của tôi là rất thực thể trung tâm, thực sự nó chỉ là keo giữa các thực thể và kho lưu trữ, với sự xác nhận ở giữa. Tôi đã nhìn thấy nhiều thiết kế, nơi Lớp Dịch vụ là thứ giữ một tham chiếu đến các kho lưu trữ (trong bản chất bỏ qua "lớp nghiệp vụ"). Về bản chất, nó phục vụ cùng một mục đích như lớp kinh doanh của tôi, nó thực hiện việc xác thực, tuy nhiên 'trách nhiệm (và đặt tên) của nó là một giao dịch kinh doanh chi tiết hơn, thô lỗ hơn. Sử dụng ví dụ trên TradingService.submitTrade() sẽ không ủy quyền cho bất kỳ lớp người quản lý doanh nghiệp nào, nó sẽ tự truy vấn các kho lưu trữ cần thiết, thực hiện tất cả xác thực, v.v.

Tôi thích thiết kế của mình theo ý nghĩa rằng tôi có thể sử dụng lại một doanh nghiệp phương pháp lớp trong nhiều cuộc gọi dịch vụ, tuy nhiên tôi ghét thực tế là đối với mỗi kho lưu trữ, tôi có một người quản lý lớp kinh doanh phù hợp, tạo ra hàng tấn công việc phụ. Có lẽ giải pháp là một loại nhóm khác ở cấp độ lớp doanh nghiệp? Ví dụ kết hợp các lớp Manager riêng lẻ như PhoneManager và EmailManager (lưu ý tôi có các thực thể Điện thoại và các thực thể Email) vào một lớp Manager hợp lý như ContactsManager (lưu ý tôi không có kiểu thực thể "Liên hệ"). Với các phương thức như ContactManager.GetPhones() và ContactManager.GetEmail(), v.v.

Tôi đoán nhiều hơn bất cứ điều gì tôi tự hỏi làm thế nào người khác tổ chức và phân công trách nhiệm, cho dù họ có lớp Dịch vụ, Lớp nghiệp vụ, cả hai, v.v. Điều gì giữ tài liệu tham khảo ngữ cảnh ORM, v.v.

Trả lời

2

Tôi có xu hướng làm những gì bạn phác thảo gần cuối mối quan tâm của bạn, và nhóm lớp doanh nghiệp đưa vào quản lý có ý nghĩa hợp lý hơn từ quan điểm kinh doanh.

Sử dụng Danh bạ chẳng hạn, tôi chắc chắn sẽ không có Trình quản lý điện thoại hoặc Trình quản lý email. "ContactsManager" là một nhóm hữu ích hơn với tôi, hoàn thành khá nhiều điều tương tự chỉ với rất ít người quản lý để giải quyết. Từ quan điểm kinh doanh, số điện thoại và email chỉ là những phần nhỏ của một Liên hệ. Chỉ vì họ có bàn và thực thể riêng của họ không có nghĩa là họ cần người quản lý của riêng mình. Điều đó không có nghĩa là bạn không thể tái sử dụng chúng.Nếu bạn có nhu cầu làm việc với các địa chỉ email ở một vài nơi, ContactsManager có thể có các phương thức liên quan.

Những gì chúng tôi có xu hướng có trong môi trường của chúng tôi là lớp cơ sở dữ liệu/tổ chức, sau đó là lớp doanh nghiệp nằm trên máy chủ và xử lý các quy tắc kinh doanh và logic nghiệp vụ. Đó là lớp kinh doanh được tiếp xúc như một dịch vụ thông qua WCF cho khách hàng (hoặc ít nhất, các công cụ có liên quan đến khách hàng là).

Có vẻ như bạn đã biết những gì bạn muốn làm, vì vậy tôi khuyên bạn nên làm một chút công việc tạo mẫu trên đó và xem nó hoạt động như thế nào cho bạn. :)

+0

Bạn đã bao giờ có một cuộc gọi dịch vụ kéo dài nhiều lớp người quản lý doanh nghiệp chưa? Nói cách khác, giao diện dịch vụ của bạn có thể còn thô sơ hơn so với các nhà quản lý doanh nghiệp. Ví dụ ContactService.CreateUser(), sẽ ủy quyền (phục vụ như một mặt tiền) cho UserManager.CreateUser() và ContactManager.AddEmail(), và ContactManager.AddPhone(), v.v. Ngoài ra, mặc dù chúng tôi đã nhóm email và điện thoại liên quan đến logic vào ContactsManager , không có gì sai khi có PhoneRepository và EmailRepository. Dường như với tôi Kho lưu trữ không thể "hợp lý" như Người quản lý. – e36M3

+0

Hiếm khi, nhưng nó đã xảy ra. Tôi muốn giữ nhiều logic trong lớp kinh doanh nhất có thể, bởi vì điều đó làm cho nó khả dụng nếu ai đó đến với tôi sau này và muốn một trang web thực hiện một số dịch vụ tương tự (và có, điều đó xảy ra). Trang web có thể gọi cùng một logic lớp nghiệp vụ mà dịch vụ thực hiện, thay vì sau đó gọi dịch vụ (chúng nằm trên cùng một máy chủ trong trường hợp của tôi). Vì vậy, những gì tôi muốn làm trong một trường hợp như thế này là có một phương pháp quản lý kinh doanh mà bản thân nó có thể sử dụng các nhà quản lý kinh doanh khác. Tôi cố gắng tránh nó trừ khi thực sự có được sự đơn giản. – Tridus

+0

Tôi biết ý của bạn là gì, tôi sử dụng DI để tạo các Nhà quản lý của mình để cung cấp cho họ các kho lưu trữ bắt buộc thông qua hàm tạo. Người quản lý tạo Người quản lý khác sẽ yêu cầu Người quản lý biết về vùng chứa DI. Tuy nhiên mà không có điều này có vẻ như đôi khi tôi nhân bản logic bằng cách sao chép và dán. Ví dụ: DataEntryManager.EnterPrice() và FileManager.UploadPriceFile(). Bạn có thể tưởng tượng rằng sau khi phân tích cú pháp "tệp giá" đã nói, chúng tôi sẽ phải chèn giá. Tôi có thể sao chép một số logic đó hoặc có FileManager tái sử dụng DataEntryManager. – e36M3

Các vấn đề liên quan