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

Question

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

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

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

конфигурация общедоступного класса :Постоянный объект {

 public decimal temperature {get;set;}

 ...(times 20)

 public decimal gravity {get;set;}

}

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

служба конфигурации ie.Создайте конфигурацию (температура, ... (x20), гравитация);

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

Конфигурация config = ConfigurationFactory.Создайте новую конфигурацию();

конфигурация.temperature = температура;

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

конфигурация.gravity = гравитация;

ConfigurationService.Сохраните новую конфигурацию (config);

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

Спасибо!

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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