Tôi nên triển khai mẫu kho lưu trữ cho các mô hình đối tượng phức tạp như thế nào?

Mô hình dữ liệu của chúng tôi có gần 200 lớp có thể được tách ra thành khoảng một chục khu vực chức năng. Thật tuyệt khi sử dụng các tên miền, nhưng sự tách biệt không rõ ràng và chúng ta không thể thay đổi nó.

Chúng tôi đang thiết kế lại DAL của chúng tôi để sử dụng Entity Framework và hầu hết các đề xuất mà tôi đã thấy đề xuất sử dụng mẫu Kho lưu trữ. Tuy nhiên, không có mẫu nào thực sự xử lý các mô hình đối tượng phức tạp. Một số triển khai mà tôi đã tìm thấy đề xuất sử dụng kho lưu trữ cho mỗi thực thể. Điều này có vẻ vô lý và không thể duy trì cho các mô hình lớn, phức tạp.

Có thực sự cần thiết để tạo một UnitOfWork cho mỗi hoạt động và Kho lưu trữ cho mỗi thực thể không? Tôi có thể kết thúc với hàng ngàn lớp học. Tôi biết điều này là không hợp lý, nhưng tôi đã tìm thấy rất ít hướng dẫn triển khai Kho lưu trữ, Đơn vị công việc và Khung thực thể đối với các mô hình phức tạp và các ứng dụng kinh doanh thực tế.

Đầu tiên, bạn sẽ chạy qua mọi thực thể mà bạn có và tự hỏi:

Liệu nó có ý nghĩa để duy trì thực thể này một mình?

Điều tôi muốn nói ở đây là trong mô hình đối tượng của bạn, một số thực thể có khả năng chứa trong các đối tượng khác trong mối quan hệ chi tiết tổng thể. Nếu thực thể của bạn phụ thuộc nhiều vào một thực thể khác, đừng tạo một kho lưu trữ cho thực thể này một mình bởi vì nó sẽ không thể tồn tại bởi chính nó. Thay vào đó, bạn sẽ tạo một kho lưu trữ cho mỗi lớp cha và bạn sẽ đảm bảo rằng các thực thể con và các mối quan hệ khác được duy trì cùng một lúc.

Tôi không thích cách họ triển khai mẫu UnitOfWork trong liên kết bạn cung cấp. Tôi đề nghị bạn làm một cái gì đó nhiều hơn dọc theo những dòng này . Bạn không phải xác định một lớp cho mỗi kho lưu trữ. Cùng một lớp có thể được sử dụng cho mọi kho lưu trữ, mỗi kho lưu trữ có thể hiện riêng của lớp UnitOfWork trong suốt thời gian hoạt động. Bạn cũng có thể sử dụng lại cùng một UnitOfWork trong các kho khác nhau cho các thay đổi mà bạn muốn duy trì cùng một lúc.

Có lẽ bạn nên xem qua Thiết kế hướng tên miền . Nó khuyên bạn nên nhóm các đối tượng của mình trong Tập hợp và chỉ tạo các kho lưu trữ cho thực thể Root của mỗi Tập hợp. Đó là một cách hay để mang lại trật tự cho một mô hình đối tượng phức tạp lớn.

Các khu vực chức năng khác nhau của bạn có thể là Bối cảnh bị ràng buộc . Có nhiều kỹ thuật khác nhau để xử lý các bối cảnh giới hạn chồng chéo nếu sự tách biệt giữa chúng không rõ ràng.

Nền tảng lý thuyết nào bạn đã tìm thấy cho thiết kế cơ sở dữ liệu "Mẫu lưu trữ"? Tôi đoán là không. Đó là một lớp phức tạp dựa trên tiền đề không có thật: rằng "lớp kiên trì" là thứ bạn cần phải tách biệt. Từ những gì tôi có thể nói, nó đóng vai trò của việc lập trình rộng rãi về sự thiếu hiểu biết về các nguyên tắc thiết kế quan hệ và những người mắc kẹt đến một trung tâm giả định của thiết kế OO của ứng dụng. Nhưng nó không biện minh cho sự tồn tại của nó trên lý trí, chứ chưa nói đến lý thuyết, căn cứ.

Thiết kế cơ sở dữ liệu One True Path đã không thay đổi sau 30 năm: phân tích dữ liệu. Tìm các khóa và ràng buộc và các mối quan hệ nhiều-một. Thiết kế bảng của bạn theo mẫu thông thường Boyce-Codd. Sử dụng các khung nhìn và các thủ tục được lưu trữ để tạo điều kiện truy cập dữ liệu.

Mặc dù không được yêu cầu, nhưng DBMS SQL cung cấp lớp cách ly tốt hơn bất cứ thứ gì lập trình viên có thể cung cấp. Đúng là khi cơ sở dữ liệu thay đổi SQL được sử dụng để truy cập, nó có thể phải thay đổi. Nhưng lưu ý rằng điều đó đúng bất kể có hay không có lớp hòa giải . Miễn là ứng dụng sử dụng các khung nhìn và các thủ tục được lưu trữ để truy cập DBMS, các công cụ kỹ thuật SQL thông thường sẽ chỉ ra khi thay đổi cơ sở dữ liệu cơ bản làm mất hiệu lực các khung nhìn và các thủ tục được lưu trữ.

Tất nhiên, đó là thách thức. Một lớp trung gian cung cấp ảo giác về sự cô lập và sự thoải mái cho người lập trình viết mã, anh ta biết cách làm. Học thiết kế cơ sở dữ liệu và SQL đòi hỏi phải học một cái gì đó mới. Hầu hết mọi người thà chết chứ không nghĩ, và nhiều người thành công.

Ai đó trong nhóm của bạn sẽ nghi ngờ rằng việc viết SQL để hỗ trợ 200 lớp của bạn là rất nhiều công việc. Không còn nghi ngờ gì nữa. Nhưng ít nhất đó là công việc hữu ích . Nếu bạn thiết kế cơ sở dữ liệu bằng cách bắt chước thiết kế OO của mình, bạn cũng sẽ làm được rất nhiều việc, phần lớn là vô dụng và đánh bại hầu hết những gì DBMS cung cấp cho bạn.

Ví dụ, bạn suy ngẫm về Đơn vị công việc phản ánh trong cơ sở dữ liệu (như bảng hoặc bảng, tôi đoán). Đơn vị của công việc là một built-in dịch vụ của DBMS: begin transaction... cập nhật cơ sở dữ liệu ... commit transaction. Không có gì để mô hình hóa, ngoài việc ánh xạ các lớp của bạn vào các bảng cơ sở dữ liệu trong SQL.

Câu hỏi của bạn đã được đăng 4 năm trước. Tôi đang trả lời vì nó đã được "cập nhật" theo một cách nào đó gần đây, cho thấy nó vẫn được ai đó quan tâm. Tôi hy vọng câu trả lời của tôi khuyến khích người đọc áp dụng lý thuyết quan hệ cơ bản cho vấn đề thay vì áp dụng một cách giải quyết vô nghĩa.