Asp.net MVC - Как добиться гибкости модулей для кросс-проекта? - PullRequest
2 голосов
/ 22 января 2010

Я не ищу код напрямую, но думаю о том, как лучше решить мою проблему.

Это приложение asv.net mvc, над которым я работаю. Он должен быть «очень модульным», и многие части должны быть повторно использованы в разных проектах.

Наш нынешний подход заключается в использовании Managed Extensibility Framework для импорта сборок во время выполнения. Они обычно состоят из всего необходимого для работы; модели, виды и контроллеры. Маршруты и кнопки навигации / главного меню регистрируются при импорте. Это работает до сих пор; Например, я могу просто скопировать сборку «колонки новостей» в любой другой проект, включить элементы MEF, и «волшебным образом» новый проект предоставляет функцию новостей, доступную по адресу /News/List.

.

Однако проблема в том, что, хотя в большинстве случаев представление по умолчанию, доставляемое в сборке, подходит, я иногда хотел бы, чтобы импортированный контроллер отображался в другом представлении, отображая другие поля в пользовательском макете. Мой текущий подход - сделать методы действий в модулях виртуальными. Если другому проекту необходимо отобразить список с помощью пользовательского представления, я просто перезаписываю метод списка, вызываю базовый метод для заполнения ViewData, а затем просто вызываю любое представление, которое мне нужно. Однако, это почему-то кажется грязным, и если кто-нибудь знает лучшее решение, я был бы очень признателен.

Другая проблема, с которой я сталкиваюсь, заключается в том, что я хочу, чтобы импортированная модель работала с другой таблицей. Мы собираемся использовать Fluent NHibernate, где целевая таблица определена в ClassMap-Table («Новости»). Сопоставления импортируются так:

foreach(Assembly assembly in assemblies)
  configuration.Mappings(m => m.FluentMappings.AddFromAssembly(assembly));

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

Спасибо, что хотя бы прочитали это:)

1 Ответ

0 голосов
/ 25 февраля 2012

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

Я также создаю базовые классы контроллеров в своих приложениях для управления созданием / удалением моего контекста EF и т. Д.

Вы можете рассмотреть возможность абстрагирования вашего доступа к данным. Даже если вы используете NHibernate и ваша стандартная реализация использует определенную схему БД, вы сталкиваетесь с довольно классической проблемой повторного использования кода: добавлением слишком много определенной логики в ваш повторно используемый пакет. Как правило, я стараюсь не допускать каких-либо особенностей базы данных в свой повторно используемый код. Я использую объекты и интерфейсы POCO, поэтому я могу использовать любой тип источника данных для создания своих объектов. Затем у меня может быть другая сборка со стандартной реализацией, использующая сервер SQL, EF, мою предпочтительную схему БД и т. Д. Однако, если мне нужно подключить ее к чему-то другому, я просто реализую интерфейс (ы) в новой версии. 1007 *

Надеюсь, что ответит на ваш вопрос.

...