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

Question

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

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

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

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

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

Что бы вы сделали здесь в этом сценарии, поскольку вы не захотите создавать совершенно новые модули, скажем, 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 или что-то еще; Дело в том, что все модули объединены в одно приложение независимо от того, как они реализованы, потому что они используют шаблоны, установленные в Prism, такие как регионы, события и т. д.

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

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

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

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

Answer 2

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

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

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

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

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

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

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