Thiết kế điều khiển tên miền và thiết kế điều khiển cơ sở dữ liệu cho ứng dụng web MVC

Question

Tôi đang mở rộng/chuyển đổi ứng dụng Biểu mẫu web cũ thành ứng dụng MVC hoàn toàn mới. Việc mở rộng cả về công nghệ cũng như trường hợp sử dụng kinh doanh. Các ứng dụng kế thừa là một Database Driven Design (DBDD) được thực hiện tốt. Vì vậy, ví dụ: nếu bạn có các loại nhân viên khác nhau như Operator, Supervisor, Store Keeper vv và bạn cần thêm một kiểu mới, bạn chỉ cần thêm một số hàng vào một vài bảng và thì đấy, giao diện người dùng của bạn sẽ tự động có mọi thứ để thêm/cập nhật loại nhân viên. Tuy nhiên sự phân tách các lớp không tốt lắm.

Dự án mới có hai mục tiêu chính

• Khả năng mở rộng (đối với hiện và yêu cầu đường ống dẫn trong tương lai)
• Performance

tôi dự định để tạo ra các dự án mới thay thế các cơ sở dữ liệu Driven Design (DBDD) với Thiết kế Điều khiển Miền (DDD) lưu ý đến yêu cầu Mở rộng. Tuy nhiên, việc chuyển từ một thiết kế hướng cơ sở dữ liệu sang thiết bị điều khiển tên miền dường như ảnh hưởng bất lợi đến yêu cầu hiệu suất nếu tôi so sánh nó với hiệu năng của ứng dụng DBDD kế thừa. Trong ứng dụng kế thừa, bất kỳ cuộc gọi nào cho dữ liệu từ giao diện người dùng sẽ trực tiếp tương tác với cơ sở dữ liệu và bất kỳ dữ liệu nào sẽ được trả về dưới dạng DataReader hoặc (trong một số trường hợp) một DataSet.

Hiện tại với DDD nghiêm ngặt tại chỗ, mọi cuộc gọi dữ liệu sẽ được định tuyến thông qua lớp Doanh nghiệp và lớp Truy cập dữ liệu. Điều này có nghĩa là mỗi cuộc gọi sẽ khởi tạo một đối tượng kinh doanh và một đối tượng truy cập dữ liệu. Một trang giao diện người dùng có thể cần các loại dữ liệu khác nhau và đây là một ứng dụng Web mà mỗi trang có thể được nhiều người dùng yêu cầu. Ngoài ra một ứng dụng Web MVC là không trạng thái, mỗi yêu cầu sẽ cần khởi tạo các đối tượng nghiệp vụ và các đối tượng truy cập dữ liệu mỗi lần. Vì vậy, nó có vẻ cho một ứng dụng không có quốc tịch MVC DBDD là thích hợp hơn để DDD cho hiệu suất.

Hoặc có cách nào để DDD đạt được cả hai, Khả năng mở rộng mà DDD cung cấp và hiệu suất mà DBDD cung cấp?

Answer 1

Bạn đã xem xét một số dạng Truy vấn lệnh lệnh trong đó các bản cập nhật thông qua mô hình miền chưa đọc có phải là DataReaders không? DDD thổi hoàn toàn không phải lúc nào cũng phù hợp.

Answer 2

Sử dụng DDD sẽ không có tác động đáng kể về hiệu suất trong trường hợp của bạn. Điều bạn lo lắng dường như giống với vấn đề truy cập dữ liệu hơn. Bạn coi nó như

khởi tạo một đối tượng kinh doanh và một Data Access Object

Tại sao 'khởi' đắt tiền? Bạn đang sử dụng cơ chế truy cập dữ liệu nào?

DDD với các đối tượng tồn tại lâu dài được lưu trữ trong cơ sở dữ liệu quan hệ thường được triển khai bằng ORM. Nếu được sử dụng đúng cách, ORM sẽ có rất ít, nếu có, tác động đến hiệu suất cho hầu hết các ứng dụng. Và bạn luôn có thể chuyển lại các phần nhạy cảm nhất về hiệu suất của ứng dụng sang SQL thô nếu có nút cổ chai đã được chứng minh.

Đối với giá trị của nó, NHibernate chỉ cần được khởi tạo một lần khi khởi động ứng dụng, sau đó nó sử dụng cùng một kết nối ADO.NET như trình đọc dữ liệu thông thường của bạn. Vì vậy, tất cả đều tóm tắt bản đồ thích hợp, tìm nạp chiến lược và tránh các lỗi truy cập dữ liệu cổ điển như 'n + 1 lựa chọn'.

Answer 3

"Hiện tại với DDD nghiêm ngặt tại chỗ, mọi cuộc gọi dữ liệu sẽ được định tuyến thông qua lớp Doanh nghiệp và lớp Truy cập dữ liệu".

Tôi không tin điều này là đúng và chắc chắn là không thực tế. Tôi tin rằng điều này nên đọc:

Bây giờ với DDD nghiêm ngặt tại chỗ, bất kỳ cuộc gọi cho một giao dịch sẽ được chuyển thông qua các lớp kinh doanh và lớp truy cập dữ liệu.

Không có gì nói rằng bạn không thể gọi trực tiếp lớp truy cập dữ liệu để tìm nạp bất kỳ dữ liệu nào bạn cần hiển thị trên màn hình. Chỉ khi bạn cần phải sửa đổi dữ liệu mà bạn cần để gọi mô hình miền của bạn được thiết kế dựa trên hành vi của nó. Theo tôi, đây là điểm khác biệt chính. Nếu bạn định tuyến mọi thứ thông qua mô hình miền của mình, bạn sẽ có ba vấn đề:

1. Thời gian - bạn sẽ mất nhiều thời gian hơn để thực hiện chức năng, không có lợi.
2. Thiết kế mô hình - mô hình miền của bạn sẽ bị bẻ cong hình dạng để đáp ứng nhu cầu truy vấn thay vì hành vi.
3. Hiệu suất - không phải do một lớp bổ sung, mà bởi vì bạn sẽ không thể lấy dữ liệu tổng hợp từ mô hình của mình nhanh như bạn có thể trực tiếp từ truy vấn. tức là xem xét tổng giá trị của tất cả các đơn hàng được đặt cho một khách hàng cụ thể - nhanh hơn nhiều để viết truy vấn cho điều này hơn là tìm nạp tất cả các thực thể đơn hàng cho khách hàng, lặp lại và tổng hợp.

Như Chriseyre2000 đã đề cập, CQRS nhằm giải quyết những vấn đề chính xác này.