2009-07-09 19 views
8

Tôi đang lập mô hình một ứng dụng ASP.NET MVC rất cơ bản bằng cách sử dụng NHibernate và dường như tôi bị kẹt trên thiết kế của mình. Dưới đây là một phác thảo của mô hình của tôi:Tôi có vi phạm ranh giới tổng hợp của mình không?

model 1 http://i29.tinypic.com/309614n.jpg

Như bạn có thể thấy điều này là rất cơ bản nhưng tôi có một số lo ngại về điều đó. Thực thể gốc người dùng và thực thể gốc Tổ chức đang truy cập cùng một thực thể Organization_Users con thông qua hai mối quan hệ một-nhiều. Điều này có vẻ không đúng và tôi nghĩ rằng tôi đang phá vỡ các ranh giới tổng hợp. Mô hình này có mùi với tôi nhưng tôi thích ý tưởng bởi vì tôi muốn có mã như thế này:

var user = userRepository.Load(1); 
var list = user.Organizations; // All the organizations the user is a part of. 

var org = orgRepository.Load(1); 
var list = org.Users; // All the users in an organization. 

Ngoài ra các dữ liệu thêm trong bảng như gắn cờ và vai trò sẽ được sử dụng bởi thực thể Tổ chức. Đây có phải là thiết kế tồi không? Nếu bạn có bất kỳ suy nghĩ nào sẽ tuyệt vời. Tôi vẫn đang cố gắng suy nghĩ về DDD. Cảm ơn

Trả lời

2

Tôi đã sử dụng phương pháp tương tự như mô hình đầu tiên của bạn trong một số trường hợp. Cách bắt giữ với phương pháp này là bạn cần phải tạo một lớp học OganizationUser trong miền của mình để xử lý các trường Vai trògắn cờ từ miền của bạn. Điều này sẽ để lại cho bạn một cái gì đó như thế này trong mã của bạn.

var user = userRepository.Load(1); 
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values. 

var organization = list[0].Organization; 

* Nếu bạn đang đi để được lặp qua tất cả một tổ chức sử dụng khá thường xuyên bạn có thể sẽ muốn tải háo hức các Tổ chức thực thể cùng với OrganzitionUser

Với thiết kế thứ hai bạn đã gửi có vẻ như bạn sẽ có thể thêm người dùng vào OrgUserDetails mà không thêm người dùng vào Tổ chức người dùng. Điều đó dường như không phải là thứ tôi muốn hỗ trợ từ Miền của tôi.

+0

Cảm ơn rất nhiều câu trả lời của bạn. Đó là cách chính xác tôi muốn thực hiện mô hình này. Bạn đã đưa ra một điểm tuyệt vời mà phải cập nhật OrgUserDetails và OrganizationUser với cùng một thông tin không phải là một ý tưởng tuyệt vời. Tôi sẽ sử dụng mô hình đầu tiên của mình và thêm lớp OrganizationUser, như bạn đã nói, vào miền Tổ chức của tôi để tôi có thể truy cập các thuộc tính bổ sung đó. Có vẻ như thế sẽ ổn thôi. Cảm ơn một lần nữa vì sự giúp đỡ của bạn! – CalebHC

4

Đây là mối quan hệ nhiều-với-nhiều điển hình. Và các bảng Organization_Users là bảng bridge. Infact NHibernate và tất cả các công cụ ORM khác có tính năng tích hợp sẵn để hỗ trợ bảng bridge.

Điều này cần được giải quyết ở cấp mô hình dữ liệu thay vì ở cấp ứng dụng. Bạn nên phân tích mô hình dữ liệu của mình và bạn nên tránh các mối quan hệ nhiều-nhiều (theo nghĩa nếu nó không phải là sự cần thiết của mô hình miền, bạn nên cố gắng tránh mối quan hệ nhiều-nhiều).

Điều đầu tiên bạn cần đảm bảo rằng mối quan hệ nhiều-nhiều trong mô hình dữ liệu là cần thiết để ánh xạ các thực thể miền. Một khi bạn đã làm điều này thì mô hình trình bày trong sơ đồ của bạn là ok cho việc lập bản đồ những mối quan hệ ở cấp ứng dụng

2

Những điều đầu tiên cần xem xét trong DDD là:

  • quên schema cơ sở dữ liệu của bạn (có không cơ sở dữ liệu!)
  • bạn sẽ thực hiện hành động nào trên các đối tượng từ góc độ tên miền?
+1

Cho đến khi bạn nhấn các vấn đề về hiệu suất và sau đó bạn cảm thấy tiếc khi bạn quên cơ sở dữ liệu :) –

1

sự hiểu biết của tôi là:

Một Người dùng có thể thuộc về Tổ chức 0-nhiều. VÀ Tổ chức bao gồm từ 0 đến nhiều Người dùng.

Cả hai có đúng không? Nếu vậy, điều đó nghe có vẻ giống như nhiều người đối với tôi.

Trong nhiều người, bạn cần nhiều đối tượng giống như mối quan hệ để thu hẹp khoảng cách đó. Vấn đề là, không có user_organization trong miền.

Điều này khiến tôi nghĩ bạn không nên có user_organization như một phần của miền của bạn, mỗi lần truy cập. Nó giống như một chi tiết thực hiện.

Mặt khác, có thể có ý nghĩa trong miền của bạn để có danh sách giữ Người dùng trong tổ chức và lưu trữ vai trò của họ và thông tin khác cụ thể cho mối quan hệ đó.

2

Tôi nghĩ rằng mô hình của bạn là tốt.Tôi thường nghĩ về nguồn gốc tổng hợp miền, khi tôi nghĩ về tất cả, về mặt những gì được công khai tiếp xúc, chứ không phải nội bộ thực hiện. Với các mối quan hệ tôi nghĩ về thực thể nào "mặc quần" trong mối quan hệ. Tức là, việc thêm Người dùng vào một tổ chức hoặc thêm một tổ chức vào một người dùng là điều tự nhiên hơn? Trong trường hợp này cả hai có thể có ý nghĩa, một người dùng tham gia một tổ chức; một tổ chức chấp nhận một người dùng cho thành viên.

Nếu miền của bạn thấy mối quan hệ từ góc nhìn của người dùng, bạn có thể đặt các phương pháp để duy trì (thêm, loại bỏ, v.v.) mối quan hệ trên người dùng và hiển thị bộ sưu tập chỉ đọc trên tổ chức.

Để trả lời thiết kế thứ hai của bạn (sẽ tốt hơn nếu bạn đã chỉnh sửa câu hỏi gốc): Tôi không thích nó chút nào. Thiết kế ban đầu của bạn là tốt. Tôi sẽ không nhất thiết bỏ qua cơ sở dữ liệu trong khi thiết kế các lớp học của bạn, một thiết kế tốt nên mô hình hóa chính xác miền và đơn giản để thực hiện trong cơ sở dữ liệu quan hệ. Đôi khi bạn phải thỏa hiệp cả hai hướng để đạt được vị trí ngọt ngào. Không có án tù vì vi phạm ranh giới tổng hợp. :-)

+0

Cảm ơn bạn đã nhập. Vâng, bây giờ tôi nhìn vào thiết kế thứ hai tôi thực sự không thích nó! :) – CalebHC

0

Cảm ơn mọi người vì câu trả lời của bạn. Họ từng rất hay giúp đỡ người khác.

Trong khi tôi đang suy nghĩ về mô hình của mình nhiều hơn một chút, tôi đã phác họa một điều gì đó mới mẻ mà tôi nghĩ sẽ tốt hơn.

alt text http://i26.tinypic.com/ic0pw4.png

Suy nghĩ của tôi là thế này:

  1. Khi người dùng đăng nhập vào trang web của hệ thống phát hiện tài khoản của họ và sau đó trả về một danh sách các tổ chức mà họ đang ngoài và nó được thông tin này từ đối tượng user_organizations.

  2. Khi người dùng nhấp vào một trong các tổ chức mà họ tách rời, họ sẽ dẫn họ đến bảng điều khiển của tổ chức.

  3. Tổ chức được chọn sau đó tra cứu vai trò của người dùng đó trong org_user_details của nó để biết người dùng nên có quyền truy cập nào vào bảng điều khiển của tổ chức đó.

Điều đó có hợp lý không? :)

Tôi cảm thấy như vậy sẽ là tốt trong một mô hình nhưng tôi có một số nghi ngờ về việc thực hiện DB. Tôi biết tôi thậm chí không nên lo lắng về nó nhưng tôi không thể phá vỡ thói quen xấu của tôi được nêu ra! Bạn có thể thấy rằng có loại dữ liệu trùng lặp trong đối tượng user_organizations và đối tượng org_user_details. Tôi không phải là một DB chuyên nghiệp nhưng đó là một thiết kế DB xấu? Thay vào đó tôi có nên kết hợp dữ liệu từ user_organizations và org_user_details vào một bảng như trong bài đăng đầu tiên của tôi và chỉ nói với NHibernate rằng Người dùng xem nó như một mối quan hệ Nhiều-nhiều và Tổ chức xem nó như một mối quan hệ Một-nhiều ? Nghe có vẻ như tôi đang lừa hệ thống. Xin lỗi nếu tôi có vẻ thực sự bối rối về điều này.

Suy nghĩ của bạn về điều này là gì? Tôi có nghĩ về điều này không? : P

+1

off-topic nhưng tôi không thể cưỡng lại ... bạn đã dùng bút nào để vẽ sơ đồ này? – MatthieuGD

+0

Lol, không sao cả. Tôi đã sử dụng một cây bút nhọn. Tôi nghĩ rằng nó sẽ hiển thị tốt cho chụp ảnh. Tôi đoán nó hoạt động ổn. Không tốt đẹp như một lớp hoặc sơ đồ UML! :) – CalebHC

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