Призма с ASP.NET

Проблема, с которой вы столкнетесь, - это разные стили времени жизни между клиентскими приложениями и веб-приложениями.

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

С другой стороны, клиентские приложения запускаются, настраивают свою среду и затем сохраняют все вокруг в памяти. Кроме того, у экземпляра клиентского приложения будет один пользователь, а не много. Оболочка и EventAggregator, в частности, полагаются на все, что находится в памяти, даже между запросами, и не делают различий между тем, кто работает (потому что в этом мире есть только один).

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

Если повторное использование кода вызывает большую озабоченность (что должно быть), я бы посмотрел на требования к жизненному циклу вашего проекта. Вам нужен этот код, чтобы прожить несколько лет, 5 лет, 10 лет? Более? Очевидно, что большинство крупных проектов хотят, чтобы их код просуществовал как можно дольше с минимальными затратами на обслуживание (или переписывание).

Причина, по которой я поднимаю этот вопрос, заключается в том, что если вы пишете свои модули кода с помощью Prism или ASP.NET, то вы привязываете свой (потенциально) повторно используемый код к этой конкретной технологии, которая может использоваться или не использоваться через 5+ лет. Это связывает ваш долгосрочный код с относительно краткосрочными технологиями. Что произойдет через несколько лет, когда будет выпущена «следующая большая вещь», и вы захотите перенести на нее свой проект? Если вы подключены к Prism или текущему ASP.NET, вам может быть сложно / невозможно переключить технологии с финансовой точки зрения.

Вам лучше абстрагироваться от логики вашего приложения и перейти к структуре верхнего уровня, не зависящей от технологий, которая может взаимодействовать с Prism и / или ASP.NET. Эта идея разделения - одна из основных причин того, что контейнеры IoC / DI (например, Unity) стали настолько популярными в последнее время. Это также значительно упрощает модульное тестирование.

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

N-уровневая инфраструктура приложений также отлично подходит, когда вы смотрите на распределенные вычисления - что происходит, когда вы хотите запустить приложение Prism на клиентском компьютере, но вы хотите разместить данные своего приложения (например, базу данных SQL Server) на сервере? Если ваш клиентский компьютер находится в вашей сети, ничего страшного - вы можете дать ему строку подключения к серверу, без проблем. Но если вы планируете получать доступ к своим данным через Интернет, вам необходимо абстрагироваться от уровня данных вашего приложения и предоставить методы для (безопасного) извлечения данных через Интернет.

Я поддержал ответ Криса, потому что он на 100% правильный с vanilla asp.net. Однако проявив немного творчества, вы можете использовать Knockoutjs, чтобы приблизиться к своей цели.

Я думаю, вы идете в мир боли. Я покопался в коде Prism, он не очень хорош и тесно связан с WPF / Silverlight. Модели очень разные, и мысль о совместном использовании кода звучит здорово, но я уверен, что это будет почти невозможно.