Если вы можете ссылаться на все библиотеки, которые вам нужны во время сборки, то вам не нужно использовать модули, определенные в Prism. В этом случае (и если ваши требования просты) использование модулей Prism может быть излишним.
Теперь рассмотрим ситуацию, когда ваше приложение позволяет вашим пользователям создавать/писать свои собственные плагины. Вы не можете заранее знать, какие плагины будут писать ваши пользователи, и поэтому вы не можете ссылаться на эти плагины при создании своего приложения. Именно здесь модули Prism заполняют пробел и позволяют вашему приложению определять с помощью конфигурации или обнаружения, какие другие модули должны быть загружены и инициализированы во время выполнения.
У меня нет большого опыта работы с Prism, но, насколько я помню, у него нет механизма загрузки по умолчанию. Если вы решили использовать MEF, то вы используете декларативные атрибуты для определения того, какие и как сборки загружаются/инициализируются. В этом случае вы можете, но не обязаны, реализовать интерфейс IModule (например, посмотрите на пример кода StockTrader RI, который не реализует IModule). Если вы не используете MEF или справочные библиотеки в своих проектах, то вы должны реализовать интерфейс IModule и определить модули в XAML, конфигурационном файле, коде или обнаружении.
Это интересно. Спасибо. Помимо сценария, который вы опубликовали, я не вижу, как часто можно будет сбрасывать в него компоненты или фрагменты приложения во время выполнения. Я думал, что это универсальная платформа для составления программного обеспечения, написанного несколькими разными программистами.
Prism был разработан для корпоративных приложений, где нередко встречаются тысячи модулей и даже тысячи разработчиков. Особенности призм (например, помощь с MVVM, GUI, навигацией, связью между модулями) имеют решающее значение для крупномасштабных приложений.
Как я уже упоминал, для небольших приложений Prism определенно может быть излишним и даже излишне усложнять реализацию. Если ваше приложение состоит только из нескольких представлений и/или сборок/модулей, и вы решили игнорировать рекомендации (например, не использовать MVVM, добавлять бизнес-логику в код позади файла, не использовать TDD/BDD и т. д.), то при возникновении проблем они все еще поддаются управлению.
Хорошо. Теперь я понимаю. Тем не менее, это не плохая идея, чтобы войти в курс дела, просто на случай, если мой следующий работодатель потребует этого. Лучше не учиться на работе.