Создание ваших доменных объектов? - PullRequest
Новая
       0

Создание ваших доменных объектов?

2 голосов
/ 17 августа 2010

Я пытаюсь изучить дизайн, управляемый доменом, поэтому я уверен, что это будет первый из многих вопросов (я уже могу вспомнить хотя бы еще пару вопросов, но не хочу разбивать свои вопросы ). Я использую «Архитектурные решения Microsoft .NET для предприятия» Дино Эспозито, который в некоторых случаях очень абстрактен.

Прежде всего, я всегда предполагал, что ваши бизнес-объекты будут иметь некоторый тип связи (передаваемый через конструктор), будь то хранилище, DBConnection или что-то еще. Похоже, я не прав.

Вы просто создаете свой доменный объект комбинацией, передающей ВСЕ данные и, возможно, некоторые функции добавления / удаления для базовых коллекций (Order -> OrderDetails)? Таким образом, в вашем DataMapper вы будете создавать объекты бизнеса из кортежей в вашей БД, а затем возвращать их на прикладной уровень через хранилище, где вы будете их использовать? Тогда и вашему прикладному уровню, и DL потребуется ссылка на ваши бизнес-объекты. Это, конечно, заставит вас встроить свой собственный ленивый механизм загрузки, если вы не используете ORM или, может быть, даже если вы используете ORM, потому что вы были бы отключены в этот момент. Вы, конечно, не захотите загружать ВСЕ базовые данные при любых обстоятельствах.

1 Ответ

3 голосов
/ 18 августа 2010

Согласно дизайну, управляемому доменом, доменные объекты остаются невежественными. Это означает, что они не должны содержать код инфраструктуры, который подключается к базе данных. Однако - абстракции хранилища рассматриваются как часть модели предметной области. Поэтому - «разрешено» их использовать, но мне лично нравится избегать этого.

Если вы говорите о моделировании доменных объектов - то нет, в основном это не очень хорошая вещь - моделировать их как глупые пакеты данных. Это приводит к анемичной модели .

Если вы говорите о реконструкции доменных объектов, когда они извлекаются из механизмов персистентности, то да - в основном это просто восстановление доменного объекта с нуля. Но сложная часть здесь - это восстановление и другие связанные с сохранением проблемы не должны вторгаться в Ваш домен. У вас не должно быть общедоступных функций добавления / удаления без каких-либо проверок, чтобы заставить ваше постоянство работать. В действительности - трудно поддерживать чистоту модели полностью (фактически, она уже испорчена используемым вами языком программирования, и не существует чистого носителя, который мог бы ее содержать, кроме реальности, которую вы моделируете сами), и всегда будут некоторые неявные зависимости (например, все должно быть помечено как виртуальное при использовании NHibernate ORM).

Но Вы не сосредотачиваетесь на том, что должны делать, если хотите понять дизайн, управляемый доменом. Ядром доменного дизайна является повсеместность языка и бизнес-модели. Это о том, как Ты думаешь . Начните с чтения «Синяя книга» . Дважды. И проверяйте это пример приложения от Szymon Pobiega, пока вы не поймете причину за этими строками кода.

РЕДАКТИРОВАТЬ: Ох ... забыл о DDD Yahoo Group , который также является хорошим источником информации.

Одна вещь, которая смущает меня в вашем посте, заключается в том, что вы не должны «моделировать» их как мешки с тупой собственностью, а «реконструировать», тогда все нормально.

Взгляните на этот (упрощенный и плохой) пример. Со стороны клиента, если вы не обманываете, вы не сможете создать нового персонажа с именем. Длина> 50. 

public class Person{
  public Person(string name){ 
      if (name.Length>50) throw new ArgumentException
        ("Person name length should not exceed 50 characters");  
      Name=name;
    }
    public string Name {get;private set;}
}

Но когда мы реконструируем объект из механизмов постоянства - обман - это именно то, что мы делаем. Мы обходим валидацию, мы устанавливаем данные напрямую, мы обходим поведение объекта, потому что данные - это то, что представляет состояние. Например. используя отражение: 

typeof(Partner).GetProperty("Name").SetValue(partner,nameFromDB);

Звучит так, как будто это очень сложная тема, и, вероятно, многие люди думают, что используют доменный дизайн ... не

Доменный дизайн при запуске действительно сбивает с толку. И самое худшее, что может случиться (и обычно случается), это когда разработчик начинает верить из ниоткуда, что он делает все правильно (был там сам. Может быть, я все еще там ):

И ... действительно ли доменно-управляемый дизайн используется в поп-культуре .NET на самом деле доменно-управляемый дизайн на самом деле

Это приводит к путанице и лжи. Некоторые пытаются объяснить почему . Некоторые просто ненавидят это.

...