Использование фабрик в презентаторах в презентаторе представления модели и проектно-ориентированном дизайн-проекте

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

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

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

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

 public decimal temperature {get;set;}

 ...(times 20)

 public decimal gravity {get;set;}

}

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

т.е. ConfigurationService.CreateConfiguration (температура, ... (x20), сила тяжести);

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

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

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

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

config.gravity = гравитация;

ConfigurationService.SaveNewConfiguration (конфигурация);

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

Спасибо!


person Mark Rogers    schedule 07.01.2009    source источник


Ответы (2)


Я бы не советовал позволять объектам вашего домена выходить из уровня домена в уровень представления. Сосредоточьтесь на презентации.

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

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

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

person moffdub    schedule 08.01.2009

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

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

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

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

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

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

person RS Conley    schedule 07.01.2009