Я повреждаю свои совокупные границы в этой модели?
Попытайтесь инстанцировать contentPanel1 вне события Load; сохраните его глобальным к классу.
6 ответов
Я несколько раз использовал подход, аналогичный вашей первой модели. Единственная загвоздка этого подхода заключается в том, что вам необходимо создать класс OganizationUser в вашем домене для обработки полей Role и Flagged из вашего домена. В результате в вашем коде останется что-то подобное.
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;
* Если вы собираетесь довольно часто перебирать все организации пользователей, вы, вероятно, захотите загрузить сущность Organization вместе с OrganzitionUser
Похоже, что со вторым отправленным вами дизайном вы сможете добавить пользователя в OrgUserDetails , не добавляя пользователя в OrganizationUser . Это не
Это типичная связь "многие-ко-многим". А таблицы Organization_Users - это таблица моста. Infact NHibernate и все другие инструменты ORM имеют встроенную функцию для поддержки таблицы мостов.
Эта проблема должна быть решена на уровне моделирования данных, а не на уровне приложения. Вам следует проанализировать свою модель данных, и рекомендуется избегать отношений «многие-ко-многим» (в том смысле, что если это не является необходимостью модели предметной области, вы должны стараться избегать отношений «многие-ко-многим»).
Первое. Во-первых, вам нужно убедиться, что отношение «многие ко многим» в модели данных необходимо для сопоставления сущностей предметной области. Как только вы это сделаете, модель, представленная на вашей диаграмме, подходит для отображения этих отношений на уровне приложения
Первое, что следует учитывать в DDD:
- забудьте схему базы данных (там нет базы данных!)
- какие действия вы будете выполнять с этими объектами с точки зрения домена?
Думаю, ваша модель в порядке. Я обычно думаю о совокупных корнях предметной области, когда я вообще думаю о них, с точки зрения того, что открыто, а не внутренней реализации. Что касается отношений, я думаю о том, какая сущность «носит штаны» в отношениях. То есть, что более естественно: добавить пользователя в организацию или добавить организацию в пользователя? В этом случае оба варианта могут иметь смысл: Пользователь присоединяется к Организации; Организация принимает пользователя для членства.
Если ваш домен видит взаимосвязь с точки зрения пользователя, вы можете поместить методы для поддержания (добавить, удалить и т. д.) отношения для пользователя и предоставить доступную только для чтения коллекцию в Организация.
В ответ на ваш второй проект (было бы лучше, если бы вы отредактировали исходный вопрос): Мне он совсем не нравится. Ваш оригинальный дизайн в порядке. Я бы не обязательно игнорировал базу данных при разработке ваших классов, хороший дизайн должен точно моделировать домен и быть простым для реализации в реляционной базе данных. Иногда вам приходится идти на компромисс в обоих направлениях, чтобы попасть в золотую середину. Нет тюремного заключения за нарушение совокупных границ. : -)
Насколько я понимаю:
Пользователь может принадлежат к организациям "0 ко многим". И Организация состоит из пользователей типа "0 ко многим".
Верны ли оба утверждения? Если так, то для меня это звучит как «многие-ко-многим».
В случае «многие-ко-многим» вам в значительной степени нужен объект, подобный отношениям, чтобы преодолеть этот разрыв. Проблема в том, что в домене нет user_organization.
Это заставляет меня думать, что вы не должны иметь user_organization как часть вашего домена как таковую. Это похоже на деталь реализации.
С другой стороны, может быть, в вашем домене имеет смысл иметь Реестр, который содержит пользователей в Организации и хранит их роли и другую информацию, относящуюся к этим отношениям.
Спасибо всем за ответы. Они мне очень помогли.
Пока я немного размышлял о своей модели, я набросал кое-что новое, что, по моему мнению, было бы лучше.
Я думал так:
Когда пользователь входит на сайт, система находит его учетную запись и затем возвращает список организаций, от которых они не входят, и получает эту информацию от объекта user_organizations.
Когда пользователь нажимает на одну из организаций, от которых они не входят, он направляет его на панель управления организации.
Выбранные Затем организация ищет роль этого пользователя в своем org_user_details, чтобы узнать, какой доступ пользователь должен иметь к панели управления этой организации.
Имеет ли это смысл? :)
Я чувствую, что это было бы хорошо для модели, но у меня есть некоторые сомнения по поводу реализации БД. Я знаю, что мне даже не стоит об этом беспокоиться, но я пока не могу избавиться от своей вредной привычки! Вы можете видеть, что в объекте user_organizations и org_user_details есть как бы повторяющиеся данные. Я не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.
Что вы думаете по этому поводу? Я слишком много думаю об этом? : P
Вы можете видеть, что в объекте user_organizations и org_user_details есть как бы повторяющиеся данные. Я не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.Что вы думаете по этому поводу? Я слишком много думаю об этом? : P
Вы можете видеть, что в объекте user_organizations и org_user_details есть как бы повторяющиеся данные. Я не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.Что вы думаете по этому поводу? Я слишком много думаю об этом? : P
m не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.Что вы думаете по этому поводу? Я слишком много думаю об этом? : P
m не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.Что вы думаете по этому поводу? Я слишком много думаю об этом? : P