Kiến trúc N-Layer

Question

Tôi đang trong tình huống mà tôi phải thiết kế và triển khai hệ thống từ đầu. Tôi có một số câu hỏi về kiến ​​trúc mà tôi muốn nhận xét và suy nghĩ của bạn.

Thông tin nhanh về dự án: Đây là ứng dụng web tập trung vào dữ liệu.

Ứng dụng sẽ được xây dựng trên Microsoft .NET Framework 4.0 với cơ sở dữ liệu MS SQL SERVER 2008.

Yêu cầu:

1. Giàu UI và mạnh mẽ hỗ trợ
2. Multi-thiết bị (mọi trình duyệt và trên mọi thiết bị)
3. lỏng

Dưới đây là sơ đồ kiến ​​trúc tôi đã xây dựng :

tại cuộc họp báo của kiến ​​trúc

1. lớp Presentation: HTML5/ASP.NET MVC + JQuery (ứng dụng web hỗ trợ đa thiết bị trong phiên bản đầu tiên)
2. Dịch vụ phân phối: WCF (XML/JSON/JSONP)
3. Lớp tên miền (Lớp kinh doanh): Tất cả logic nghiệp vụ
4. Độ bền dữ liệu (DAL Layer): Khuôn khổ thực thể 4.0 với phương pháp tiếp cận cơ sở dữ liệu đầu tiên. POCO thực thể được tạo ra và tách ra sử dụng T4 mẫu
5. hạ tầng lớp: Chứa các thư viện phổ biến như thực thể POCO, Xử lý ngoại lệ, đăng nhập vv

Mối quan tâm của tôi:

1. Như ứng dụng được xây dựng kết hợp lỏng lẻo vì vậy trong tương lai nếu yêu cầu kinh doanh phát triển các mô-đun mới có thể dễ dàng được cắm vào mà không ảnh hưởng đến kiến ​​trúc. Vì vậy, tôi nghĩ đến việc sử dụng các mẫu Repository cùng với IoC và DI (có thể Unity/Ninject/Sprint.NET hoặc bất kỳ khác)
2. WCF với cả XML và hỗ trợ JSON
3. Distributed Service Layer để đặt IoC & DI
4. Exception Handling & Logging sử dụng Thư viện Enterprise 5,0

Looking for ý kiến ​​quí báu và đề xuất. Nếu tôi làm bất cứ điều gì sai, hãy đưa tôi đi đúng hướng.

Answer 1

Có nghĩa là các giao diện người dùng WPF, WinForm vv sẽ gọi lớp WCF. Tôi giả định rằng đó là một yêu cầu kinh doanh để có nhiều giao diện người dùng, nếu không, nếu bạn chỉ có thể có một giao diện người dùng, giao diện người dùng web đáp ứng là lựa chọn linh hoạt nhất.

Tuy nhiên, tôi không nghĩ giao diện người dùng MVC của bạn cần sử dụng lớp WCF. Nó có thể gọi trực tiếp lớp miền. Điều đó sẽ nhanh hơn và loại bỏ một lớp vô nghĩa.

Rõ ràng, điều đó sẽ chỉ hoạt động miễn là bạn không đặt bất kỳ logic nào trong lớp WCF của bạn. Và WCF lớp thực sự không nên có bất kỳ logic trong đó.

Bạn cũng nêu rõ rằng bạn muốn đặt IoC & DI trong Lớp dịch vụ phân tán. Điều đó không có ý nghĩa nhiều về mặt giao diện người dùng MVC của bạn. Bạn sẽ cần phải sử dụng DI trong dự án MVC để bạn có thể kiểm tra đơn vị bộ điều khiển.

Answer 2

Làm thế nào mà sơ đồ kiến ​​trúc không sử dụng lớp miền cho ASP.NET?

Dường như với tôi rằng bạn có thể đang kiến ​​trúc quá mức ứng dụng của mình. Ngoài ra, trong khi nó trông tuyệt vời để hỗ trợ 6 (hoặc hơn) công nghệ front-end khác nhau, nỗ lực để duy trì tất cả chúng sẽ là khủng khiếp. Tôi muốn gắn bó với một công nghệ cho front-end - rất có thể là HTML5 với MVC phía máy khách hoặc tương tự.

Answer 3

Tôi sẽ đề xuất nhận xét sau: ngay từ đầu, cách tiếp cận của bạn sẽ tạo khớp nối chặt chẽ. Điều này đi trực tiếp dựa vào yêu cầu của bạn # 3 "Được ghép nối lỏng lẻo"

Trong sơ đồ của bạn, bạn đã xác định hai mô-đun. Module chính, và Module 2. Tôi đoán rằng hai mô-đun này khá khác biệt với nhau. Ý tôi là điều này có nghĩa là bạn có thể phát triển chúng một cách hoàn toàn riêng biệt và sau đó cắm chúng vào, bởi vì mối quan tâm của doanh nghiệp mà chúng giải quyết là khác nhau.

Tuy nhiên, cách tiếp cận của bạn hiện tại kiến ​​trúc:

• cặp vợ chồng Main Module và Mô-đun 2 dữ liệu vào cơ sở dữ liệu cùng
• cặp vợ chồng Main Module và Mô-đun 2 đối tượng kinh doanh vào các lớp kinh doanh cùng
• cặp vợ chồng chính Mô-đun và dịch vụ Mô-đun 2 vào cùng một lớp dịch vụ
• Các cặp vợ chồng triển khai và quản lý Mô-đun chính và Mô-đun 2

Điều gì có thể đáng xem xét: Xây dựng Mô-đun chính và Mô-đun 2 làm ngăn xếp dịch vụ dọc riêng biệt.

Những gì tôi có nghĩa là chính Mô-đun và Mô-đun 2 trở Dịch vụ chính và Dịch vụ 2

Mỗi dịch vụ có nó cơ sở dữ liệu riêng, đó là lớp kinh doanh riêng, đó là lớp dịch vụ riêng và nó thành phần UI riêng.

Tuy nhiên, điều này làm tăng sự quan tâm: Dịch vụ và Dịch vụ chính 2 có thể hoạt động cùng nhau như thế nào để tạo sản phẩm của tôi?

Để giải quyết điều này:

1. Vào cuối UI, bạn khâu cuối trước của bạn với nhau bằng cách sử dụng client-side code để tải phản hồi từ các dịch vụ chính và Dịch vụ 2 vào một lần xem.

2. Ở mặt sau, bạn sử dụng xuất bản thông báo đăng ký để cho phép Dịch vụ chính đăng ký các sự kiện xảy ra trong Dịch vụ 2 và ngược lại.

Điều này sẽ dẫn đến một ứng dụng được xây dựng từ đầu trên các ngăn xếp dịch vụ dọc theo chiều dọc, duy trì sự nhất quán bằng trao đổi thư không đồng bộ.

Nếu sau đó bạn cần thêm mô-đun mới vào ứng dụng, bạn có thể tạo ngăn xếp dịch vụ mới hỗ trợ khả năng mong muốn và kết nối với ít hoặc thậm chí không cần thay đổi các ngăn xếp khác (lý do duy nhất) để thay đổi các ngăn xếp hiện có sẽ là họ muốn đăng ký các sự kiện từ mô-đun mới).

Đó là một cách tiếp cận rất khác với phương pháp bạn đang đề xuất, nhưng một phương pháp cho phép bạn đáp ứng yêu cầu cho khớp nối lỏng tốt hơn, trong ý kiến ​​của tôi.

Answer 4

Nhìn vào sơ đồ của bạn tôi có một vài điểm tôi không rõ ràng về:

• Đâu là mô hình tên miền? Domain Core hoặc 'model' trong lớp persistence?
• Lớp miền tương tác với lớp truy cập dữ liệu như thế nào? Sự tương tác không rõ ràng giữa lớp dịch vụ/ứng dụng và lớp miền.
• Sự khác biệt giữa một kho lưu trữ trong lớp tên miền và một kho lưu trữ trong lớp truy cập dữ liệu là gì? Tôi thường phân biệt việc có 'kho lưu trữ mô hình' trong lớp miền hoạt động trên các đối tượng mô hình miền và 'cổng dữ liệu' trong lớp truy cập dữ liệu hoạt động trên DTO.
• Lõi miền là gì? Đây có phải là việc thực hiện các giao dịch tầng ứng dụng không?
• Có cần phải trừu tượng hơn nữa về khuôn khổ kiên trì không? (EF)