Khi nào nên giới thiệu tầng dịch vụ ứng dụng trong ứng dụng n tầng

Tôi đang phát triển một ứng dụng dựa trên web với mục tiêu chính là lấy dữ liệu từ cơ sở dữ liệu, hiển thị nó trên giao diện người dùng, nhập dữ liệu người dùng và ghi lại vào cơ sở dữ liệu. Ứng dụng sẽ không thực hiện bất kỳ thuật toán cường độ công nghiệp nào, nhưng sẽ nhận được số lượt truy cập rất cao vào thời gian cao điểm (được mô tả dưới đây) sẽ thay đổi qua ngày.

Các lớp là Trình bày, Kinh doanh, Dữ liệu điển hình của bạn. Lớp dữ liệu được chăm sóc bởi máy chủ cơ sở dữ liệu. Lớp nghiệp vụ sẽ chứa thành phần DAL để truy cập máy chủ cơ sở dữ liệu qua tcp. Các lựa chọn tôi phải tách các lớp này thành các tầng là:

1. Các lớp trình bày và kinh doanh có thể được giữ trên cùng một tầng.
2. Lớp trình bày trên một tầng riêng biệt và lớp kinh doanh trên một tầng riêng biệt.

Trong trường hợp lựa chọn 2, lớp nghiệp vụ sẽ được truy cập bởi lớp trình bày bằng dịch vụ WCF qua http hoặc tcp.

Tôi không thấy bất kỳ quá trình xử lý nặng nào được thực hiện trên lớp Business, vì vậy tôi nghiêng về tùy chọn 1 ở trên. Tôi cũng cảm thấy vì lý do tương tự, thêm một tầng mới sẽ chỉ giới thiệu độ trễ mạng. Tuy nhiên, về khả năng mở rộng trong trường hợp tôi cần mở rộng hoặc mở rộng quy mô, cách nào tốt hơn để đi? Ứng dụng này sẽ cần có khả năng hỗ trợ tới 6 triệu người dùng mỗi giờ. Sẽ có một lượng dữ liệu hợp lý trong mỗi phiên người dùng, lưu trữ tùy chọn của người dùng và các chi tiết khác. Tôi cũng sẽ sử dụng bộ nhớ đệm cấp trang.

Tôi đồng ý với đánh giá ban đầu của bạn. Có lẽ không có ý nghĩa gì khi thêm một bước nhảy mạng bổ sung vào quá trình xử lý hệ thống của bạn. Lý do mọi người tách các lớp vật lý là để tái sử dụng trên các ứng dụng. Đó là bạn có nhiều ứng dụng gọi cùng một dịch vụ để thực hiện một phần công việc của họ. Như bạn đã đề cập, không có nhiều logic được xây dựng trong lớp nghiệp vụ; và cho đến nay chỉ có một ứng dụng sử dụng nó.

Thật tốt khi bạn đã tách các tầng một cách hợp lý nhưng một sự tách biệt vật lý tại thời điểm này có thể là quá mức cần thiết.

Cập nhật để giải quyết các mối quan tâm về khả năng mở rộng

Tôi vẫn sẽ lập luận rằng việc giữ BLL trên cùng một lớp vật lý như lớp trình bày là cách tiếp cận tốt nhất hiện nay. Bạn có thể mở rộng quy mô bằng cách thêm nhiều nút trình bày / bll (đã được xử lý nếu bạn đang sử dụng triển khai ứng dụng khách béo, đủ đơn giản để thực hiện với ứng dụng web). Ngoài ra nếu bạn thấy rằng cơ sở dữ liệu đang trở thành nút cổ chai, hầu hết các cơ sở dữ liệu đều hỗ trợ phân cụm / shending và các thủ thuật gọn gàng khác để mở rộng quy mô. Chỉ sau khi tôi đi xuống cả hai đường dẫn này (và tất nhiên là thêm vào bộ nhớ đệm phân tán), tôi mới xem xét thêm một tầng vật lý khác.

Tuy nhiên, trước khi bạn có thể đến đó, tôi sẽ bắt đầu xem xét việc tạo một Lớp nghiệp vụ "thịnh soạn" hơn là một mặt tiền đơn giản cho Lớp truy cập dữ liệu. Bước đầu tiên là xem xét sử dụng một O / RM mạnh mẽ thực hiện ánh xạ dữ liệu cho bạn. Sau đó xem xét làm cho các đối tượng kinh doanh của bạn thông minh hơn. Có những ram giấy được viết trên Domain Driven Design (cuốn sách là một nơi tuyệt vời để bắt đầu). Trải qua các bước của mô hình hóa miền, xác định bối cảnh giới hạn và tìm ra các gốc tổng hợp sẽ giúp bạn tạo ra một kiến ​​trúc có các đường nối tự nhiên. Điều này sẽ giúp phân chia ứng dụng của bạn thành các dịch vụ độc lập có thể mở rộng độc lập khi cần thiết.

Tôi giả sử rằng bạn đang sử dụng thuật ngữ "tier" có nghĩa là một máy chủ vật lý. Nếu bạn không cần phân phối lớp kinh doanh và trình bày, tôi chắc chắn sẽ tránh nó. Gửi các đối tượng qua dây là tốn kém và dễ xảy ra các vấn đề mà nếu có thể tránh được. Nhưng bạn nên thiết kế kiến ​​trúc của mình theo cách giúp dễ dàng thêm nhiều tầng hơn khi hệ thống phát triển và cân nhắc thiết kế phân phối bảo đảm. Tôi thường phát triển một lớp dịch vụ ứng dụngnhư một thư viện lớp / lắp ráp sẽ có cùng giao diện mà dịch vụ WCF của bạn sẽ có. Đây là những gì lớp trình bày giao diện với hoặc bất kỳ hệ thống bên ngoài khác. Nếu các lớp trình bày và kinh doanh không cần phải được phân phối thì lớp trình bày tham chiếu trực tiếp thư viện lớp. Nếu chúng cần được phân phối thì dịch vụ WCF của bạn chỉ là một lớp bọc mỏng xung quanh thư viện lớp dịch vụ cung cấp khả năng truy cập dịch vụ từ xa.

Để mắt đến tương lai thường là một điều tốt, nhưng giới thiệu một lớp Dịch vụ, hoặc bất cứ điều gì thực sự, khi không cần thiết có thể chỉ là lãng phí thời gian và làm chậm hệ thống của bạn.

Chia hệ thống của bạn một cách chính xác thành các lớp logic chắc chắn là một điều tốt và sẽ cho phép bạn mở rộng hệ thống của mình vào một ngày sau đó. Giảm khớp nối sẽ giúp thực hiện điều này dễ dàng hơn trong tương lai.

Khi điều đó xảy ra, tôi đã làm việc trên một hệ thống lớn vài năm trước đó là một trang web -> lớp dịch vụ -> mọi thứ khác.

Lớp Dịch vụ được giới thiệu vì tất cả các kiến ​​trúc sư / nhà quản lý cấp cao đều yêu thích SOA, vì vậy hệ thống của chúng tôi HAD trở thành định hướng dịch vụ. "Các hệ thống khác sẽ sử dụng chức năng tầng giữa của trang web của chúng tôi" là tiếng kêu.

Quyết định đó một mình khiến dự án bị chậm trễ một năm.