Призма: Ищете идеи о том, как создавать приложения, которые не обязательно соответствуют стандартным региональным макетам

Question

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

Чтобы лучше объяснить, я попытаюсь использовать пример Northwind. У меня есть 3 модуля, заказы, клиенты & сотрудников.

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

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

У вас есть эти модули, и вы понимаете, что вам нужно иметь возможность показывать Заказы для клиентов или продавцов, которые явно являются сотрудниками.

Что бы вы сделали в этом сценарии, так как вы не хотели бы создавать совершенно новые модули для say employeeOrders и customerOrders, и вы не захотите дублировать код, связанный с заказом.

Я начинаю задаваться вопросом, возможно ли думать о создании составного приложения с использованием призмы, если вы создаете приложение, такое как Outlook, но для бизнес-приложения LOB мне еще предстоит найти хороший пример того, как для этого и не нарушать некоторые принципы MVVM и определения Prism для этого.

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

Любые мысли?

Answer 1

Для этих типов коммуникационных сценариев вы должны использовать Event Aggregator. По сути, вы хотите, чтобы модуль обеспечивал функциональность, но также выставлял события, которые могут быть вызваны из других модулей. Вы также можете зарегистрировать услугу в контейнере Unity. Например:

public interface ICustomerOrderInvoker 
{ 
    void DisplayCustomerOrdersInRegion(string customerId, string regionName); 
} 

Эти методы несколько ортогональны MVVM. Обработчик событий может создать пару view/viewmodel и вставить их в область. Или ваш обработчик событий может создать UserControl со всеми функциональными возможностями, реализованными в коде, и добавляет его в регион. Красота композитного интерфейса заключается в том, что ваши модули могут использовать MVVM, а модули другой команды могут использовать прямолинейные пользовательские элементы управления или MVP или MVC или что-то действительно; дело в том, что все модули компонуются в одно приложения, независимо от того, как они реализуются, поскольку они используют шаблоны, установленные в Призма, как регионы, события и т.д.

В вашем конкретном случае:

Вы имеете эти модули выложены и понимают, что вам нужно показать Заказы для клиентов или продавцов, которые явно являются сотрудниками.

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

Точка призмы состоит в том, чтобы создавать логически раздельные и свободно связанные части функциональности.Это не означает, что модули не взаимодействуют друг с другом, а скорее, что связь происходит ограниченным и слабо связанным образом. Вы можете, конечно, писать приложения LOB с использованием этого шаблона и MVVM; многие из нас были годами. :)

Answer 2

Im работает над подобной проблемой (и я тоже новичок в Prism), пока у меня нет решения. Я думаю, что при использовании Prism его соблазн использовать структуру, как предполагает эталонная реализация, но это не обязательно так.

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

Что я делаю/намереваясь сделать, это создать MainModule, который имеет в себе большую часть моей основной функциональности, включая пользовательский элемент управления MainView/MainViewModel. Затем оболочка имеет одну область «Main» и нагрузку MainModule, которую вводит MainView в соответствии с обычным использованием призмы.

Я использую диспетчер стыковки от Telerik (совместимый с Silverlight и WPF) в MainView и реализовал класс класса IDockingManager/DockingManager в инфраструктуре, который зарегистрирован в Unity как singleton (ContainerControlledLifetimeManager) в загрузчике.

Anywhere in my app Я могу получить экземпляр IDockingManager и ввести представление, вызвав IDockingManager.DockView (представление IView, DockingParameters args). DockingParameters могут содержать информацию, например, о том, где стыковать (левый, правый, верхний, нижний, вкладные документы), а также родительский контейнер для стыковки.

Это та часть, которую я еще не получил - я могу док-станцию left/right/top/bottom на главном экране, но я хочу реализовать прикрепленное свойство или что-то в моих дочерних представлениях, регистрируя их как DockSite при стыковке. Так, например, я мог бы состыковать Treeview слева и докнуть под ним список, используя имя Treeview в качестве родительского DockSite и DockBottom в качестве стороны.

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