DDD вместе с коллекциями - PullRequest
Новая
       5

DDD вместе с коллекциями

0 голосов
/ 16 сентября 2010

предположим, у меня есть классы домена: 

public class Country
{
   string name;
   IList<Region> regions;
}

public class Region
{
   string name;
   IList<City> cities;
}

etc.

И я хочу смоделировать это в графическом интерфейсе в виде дерева. 

public class Node<T>
{
  T domainObject;
  ObservableCollection<Node<T>> childNodes;
}

public class CountryNode : Node<Country>
{}

etc.

Как я могу автоматически получить список регионовизменения для страны, список городов для региона и т. д .?

Одним из решений является реализация INotifyPropertyChanged для классов доменов и изменение IList <> на ObservableCollection <>, но это кажется неправильным, потому что почему в моей модели домена должна быть ответственностьуведомить об изменениях?

Другое решение состоит в том, чтобы возложить эту ответственность на уровень GUI / представления, если какое-либо действие привело к добавлению региона в страну, уровень представления должен добавить новую страну в оба CountryNode.ChildNodes.и домен Country.Regions.

Есть мысли по этому поводу?

Ответы [ 2 ]

2 голосов
/ 27 сентября 2010

О событиях - самый ценный материал, который я видел, получен от Уди Дахана и Грега Янга .

Одна хорошая реализация событий, к которой я стремлюсьпопробовать можно найти здесь .

Но начните с понимания, если это действительно необходимо, как предполагает Джозеф.

2 голосов
/ 21 сентября 2010

Включение INotifyProperty в решение является частью внедрения событий в вашу модель.По своей природе само событие не противоречит мантре DDD.Фактически, это одна из вещей, которые Эванс подразумевал, что отсутствовало в его более раннем материале.Я точно не помню где, но он упоминает об этом в этом видео; То, что я узнал о DDD со времени выхода книги

Само по себе осуществление модели событий на самом деле является законным в домене, потому что оно вводит разделение между доменом идругой код в вашей системе.Все, что вы делаете, это говорите, что ваш домен имеет возможность уведомлять заинтересованные стороны о том, что что-то изменилось.Таким образом, подписчик обязан действовать в соответствии с ним.Я думаю, что в этом заблуждение заключается в том, что вы используете только реализацию INotifyPropertyChanged для ретрансляции назад к приемнику событий.Затем этот приемник уведомит всех подписчиков посредством зарегистрированного обратного вызова о том, что «что-то» произошло.

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

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

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

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

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

...