Структура ASP.NET MVC 3 - перейти к просмотру в другом проекте

У меня есть следующая настройка проекта

Проект А (основной)

Business Data View (asp.net mvc 3 project)

Проект N

Business Data View (asp.net mvc 3 project)

Как я могу вызвать из Проекта А Вид из Проекта N и из N обратно в А. По сути, я пытаюсь сделать так, чтобы каждый Проект N упаковал свой собственный MVC, как он исходит из разных источников, и подключил его к Основной проект, а затем просто перейти к правильному виду.

Можно ли это сделать? Или есть лучший способ сделать это?

Ответы на вопрос(2)

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

К сожалению, без специального провайдера виртуального пути вы не можете перекрестно ссылаться на представления между несколькими приложениями ASP.NET MVC. Это просто не разрешено поставщиком по умолчанию, который ищет представления только внутри текущего приложения.

 24 июн. 2012 г., 15:12
Вы также можете взглянуть на генератор Razorrazorgenerator.codeplex.com для простого способа компилировать представления в сборки.
 fes22 июн. 2012 г., 23:29
Спасибо, Дарин, сейчас я смотрю статьи. Первое впечатление, что он выглядит довольно сложным, поэтому посмотрим, возможно ли это.
Решение Вопроса

Я предлагаю другой подход, если это возможно. если я правильно понял, эти проекты как-то являются плагинами ike, но они не являются автономными приложениями. Также они теперь друг о друге, поэтому они связаны. Это, скажем так, сложно, но я бы использовал только 1 проект asp.net mvc (веб-интерфейс). Все биты пользовательского интерфейса, которые принадлежат другим проектам, я делаю их помощниками (в значительной степени виджетами). Это означает, что каждый проект содержит только помощников, которые будут использоваться для построения представления.

Я думаю, что это немного архитектурная проблема, если вы хотите сохранить представления в каждом проекте только для размещения их в другой сборке. Переход на виджеты & apos; Может показаться, что это больше работает, но я думаю, что вы получаете максимальный контроль и уровень разделения, который вы хотите. Единственное, что у вас не определены полные представления, но почему вы хотите иметь полные представления (частичные, макеты) в отдельных местах, если они будут использоваться только в одном месте ?!

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

 fes24 июн. 2012 г., 17:18
Привет, Майк, я думаю, ты понял мою идею. Я думаю, что это почти как подход Widget, который я использую, и, хотя он немного более связан, я все еще могу изменить источник данных и просто обновить сборки без перекомпиляции всего веб-сайта.

Ваш ответ на вопрос