Использование фабрик в Presenters в представлении модели Presenter и домене, управляемом проектом разработки

Question

В дизайне, управляемом доменом, представляется хорошей практикой использовать фабрики для создания ваших доменных объектов на уровне вашего домена (в отличие от использования прямого конструктора или IoC).

Но как насчет использования фабрик доменных объектов на уровне презентатора? Например, скажем, что я создавал объект домена из пользовательского ввода, полученного от докладчика.

Вот пример, скажем, у меня есть объект конфигурации домена, который имеет несколько десятичных параметров.

Конфигурация открытого класса: PersistantObject {

 public decimal temperature {get;set;}

 ...(times 20)

 public decimal gravity {get;set;}

}

Чтобы создать этот объект на уровне домена, а не на уровне презентатора, мне нужно было бы передать каждое из этих десятичных значений в качестве параметров функции. Создание громоздкого определения функции и вызов.

т.е. ConfigurationService.CreateConfiguration (температура, ... (x20), гравитация);

Возможно, лучшим решением было бы создание объекта конфигурации на уровне презентатора и назначение всех значений объекта конфигурации непосредственно из пользовательского ввода, пропуская длительный вызов функции.

Конфигурация конфигурации = ConfigurationFactory.CreateNewConfiguration ();

config.tempera = температура;

.. (x20) .. = ...;

config.gravity = gravity;

* +1025 * ConfigurationService.SaveNewConfiguration (конфигурация); * * одна тысяча двадцать шесть

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

Спасибо!

Answer 1

Я бы не советовал пропускать ваши доменные объекты из доменного уровня в слой презентации. Держите презентационный слой сфокусированным на презентации.

По этой причине я создаю объекты передачи данных, чтобы перетасовывать данные в и из уровня домена и представления. В вашем случае попросите диалоговое окно заполнить DTO, который передается вашему сервису и переводится в соответствующий объект домена.

Вы не хотите каждый раз создавать доменные объекты из DTO. Рассмотрим случай, когда DTO представляет только подмножество объекта домена . Реконструкция существующего доменного объекта из такого DTO даст вам частичный доменный объект. Вы, вероятно, захотите поддерживать легкий кеш, в котором содержится полный объект домена, чтобы вы могли выполнить правильное обновление.

По сути, вы пришли бы к решению DTO, если бы применили рефакторинг Ввод объекта параметров .

Answer 2

Есть два основных способа справиться с этим

1) Если это настроено через диалог, я бы создал классы, реализующие шаблон команды, и связал бы диалог с рассматриваемым объектом. Например, CmdCreateConfigurationService и CmdEditConfigurationService.

CmdCreateConfigurationService будет полагаться на фабричный класс и минимальные параметры, необходимые для выбора правильной службы конфигурации.

Вы устанавливаете интерфейс IConfigurationServiceEditor и передаете его в качестве одного из параметров в Параметры CmdEditConfiguration. С интерфейсом IConfigurationServiceEditor вы определяете столько методов, сколько вам необходимо, чтобы сделать передачу информации из диалога и в него максимально простой и безболезненной. Я рекомендую использовать коллекцию ключей и значений. Объект Command знает, как настроить службу конфигурации из этой коллекции. Диалог знает, что ожидать этой коллекции при настройке.

Независимо от структуры данных вы будете выполнять работу по заполнению Сервиса конфигурации в объекте команды. Имея не диалоговый / форма / экранный объект, реализующий IConfigurationServiceEditor, вы можете автоматизировать тестирование и при определенных обстоятельствах упростить настройку сложных объектов.

Я разработал этот метод для программного обеспечения CAD / CAM, которое имеет несколько десятков параметрических фигур, каждая из которых имеет от 4 до 40 записей.