Зачем использовать призму?

Question

Я заинтересован в создании достойного приложения WPF, которое будет довольно огромным. Кто-то предложил использовать PRISM, который мы сейчас изучаем. Мы могли бы использовать шаблон MVVM для реализации этого приложения. Я видел несколько скринкастов PRISM, и кажется, что PRISM в основном используется для введения регионов с разными взглядами. Это основная цель использования ПРИЗМЫ?

Я всегда могу использовать WPF MasterPages с помощью ContentPresenter, так почему я должен использовать PRISM для региональных целей?

Answer 1

Prism предлагает немного больше, чем система региона. Не исчерпывающе:

• Система команд View-Model
• Агрегатор событий, для отсоединенной обработки событий (со множеством встроенных опций, таких как вызов потока GUI, слабые ссылки и т. Д.)
• стандартный способ загрузки модулей, если вам нужна такая гибкость

Система регионов также представляет собой нечто большее, чем просто «оболочка для предъявителя контента». Его можно использовать для «проталкивания» (представления вида в регион) или «вытягивания» (пусть модули объявляют, какой регион они заполняют). Он также поддерживает гораздо больше, чем простые области Contentpresenter (например, области на основе ItemsControl) и расширяется с помощью адаптеров областей.

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

Answer 2

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

Преимущество компоновки состоит в том, что каждый из компонентов в пользовательском интерфейсе может быть разработан индивидуально и затем связан вместе в конце производственного цикла. Это означает, что вы сгенерировали компоненты, которые можно легко использовать в нескольких местах, и ваше взаимодействие между компонентами происходит через четко определенный интерфейс, а не типичный подход «бросить компоненты на странице и общаться с состоянием».

Итак, если то, что вы делаете сейчас, сработает, я, вероятно, продолжу с этим. Если то, что у вас есть, недостаточно развито, рассмотрите что-то вроде PRISM, если у вас есть много разработчиков, работающих над частями и частями, и другой разработчик или группа, объединяющие эти части в полноценный пользовательский интерфейс для пользователя. Мой опыт работы с блоком приложений Composite UI, который принес много полезного в крупных проектах, но обещанные упрощения звучат хорошо даже для проектов небольшого размера.

Answer 3

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

Я также хотел бы сказать, что MVVM определенно подходит для этого, но CAG также рекомендует вам использовать внедрение зависимостей для ваших моделей ViewModel, делая их более тестируемыми, чем они могли бы быть в противном случае. Конечно, вы можете использовать внедрение зависимостей без CAG, но приятно иметь это формальное поощрение.

Answer 4

Если вы знаете, составной блок приложения, это в основном то же самое. Основной целью PRISM является создание составного приложения WPF, в котором каждая часть приложения (т.е. часть экрана или невидимый компонент) приложения слабо связана с другой частью приложения.