Лучшая практика для обработки отношений родительской формы с дочерней формой с использованием модели представления

Question

Согласно примечаниям к Presentation Model Мартина Фаулера, а также к документации MSDN о Presentation Model, поясняется, что класс Presentation Model не должен знать о классе пользовательского интерфейса, а класс Business Model не должен знать о классе Presentation Model.

Пользовательский интерфейс должен активно связываться с моделью представления, модель представления, в свою очередь, будет координировать работу с одним или несколькими объектами модели предметной / бизнес-модели для выполнения работы. Модель представления в основном представляет данные модели предметной области таким образом, чтобы обеспечить максимальное связывание данных в пользовательском интерфейсе, позволяя пользовательскому интерфейсу принимать как можно меньше решений и, таким образом, повышать тестируемость поведения представления. Это также делает класс модели представления универсальным, т.е. независимым от какой-либо конкретной технологии пользовательского интерфейса.

Теперь предположим, что есть форма списка (скажем, CustomerList), есть другая форма Root (скажем, Customer) и есть вариант использования, позволяющий редактировать клиента из формы CustomerList одним нажатием кнопки.

Для простоты обсуждения учтите, что некоторые действия выполнялись, когда список клиентов открывался из меню (т. Е. Щелкнуло меню клиента), а список клиентов отображался из события щелчка меню.

Теперь, согласно описанному выше варианту использования, мне нужно открыть пользовательский интерфейс клиента (один клиент) из списка клиентов. Как мне это сделать?

1. Создание необходимых объектов (BusinessModel, PresentationModel, UI) в событии нажатия кнопки «Редактировать» и оттуда вызова пользовательского интерфейса CustomerEdit?

2. Создать пользовательский интерфейс CustomerEdit из класса модели презентации и показать пользовательский интерфейс из модели презентации? это может быть сделано любым из двух способов ниже - а. Создайте объекты в следующей последовательности DomainModel-> PresentationModel-UIForm б. Используйте Unity.Resolve (); В любом случае, Presentation Model нарушается, поскольку P-модель теперь должна ссылаться на конкретную сборку пользовательского интерфейса, где находится CustomerEdit. Также P-модель должна ссылаться и использовать WinForm напрямую, что делает ее менее зависимой от технологии пользовательского интерфейса.

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

• Раджарши

Answer 1

как насчет внедрения IEditCustomerService в PresentationModel CustomerList, который вызывается в случае, если выбранный клиент должен быть отредактирован. Затем этот сервис либо сам «строит необходимые объекты», либо делегирует эту задачу IViewManagerService, который знает, какие интерфейсы доступны для редактирования объектов, какой следует использовать для конкретного, и как создать компонент интерфейса пользователя. , Конечно, вы также можете избежать одной косвенной ошибки, вставив IViewManagerService непосредственно в PresentationModel, или вы можете использовать DI-контейнер для ее разрешения.

Другая возможность состояла бы в том, чтобы позволить реализации IViewManagerService прослушивать EditCustomerEvents, запущенные PresentationModel CustomerList.

Answer 2

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

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