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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

Если вы уже компонуете свои страницы таким образом, чтобы различные подкомпоненты страницы были независимыми, PRISM (или предварительный пакет Composite UI Application Block) не покупает вас гораздо больше, чем признанный "стандартный" способ выполнения компоновки, которая документирована.

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

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

Ответ 3

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

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

Ответ 4

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