«наследование» сайтов ASP.NET MVC из общего приложения шаблонов? (multi-tenancy)

Question

Мы строим около 10 сайтов ASP.NET MVC, которые имеют общий набор функций (и соответствующие URL-адреса, маршруты, контроллеры, действия и представления). На всех сайтах также будет использоваться базовый набор объектов домена (например, пользователей, компаний) и базовые атрибуты для этих объектов (например, имя, адрес и т. Д.).

Но каждый сайт также будет очень индивидуальным и расширен с базы. Например, наш сайт для крупных публичных компаний будет иметь поля «Вспомогательный» и «Фондовый символ» на объекте домена компании, а наш сайт для стартапов будет иметь атрибуты «Венчурная фирма» и «Финансирование». Внешний вид также будет значительно отличаться, хотя мы стараемся, чтобы HTML был максимально согласован (по модулю дополнительных полей формы для дополнительных атрибутов объекта домена и т. Д.). Мы также будем переориентировать изображения экономно, поэтому мы можем, например, повторно использовать одну и ту же графику кнопок на сайтах.

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

Я знаком с тем, как обрабатывать ограниченную настройку многопользовательской аренды, как вы находите в StackOverflow/SuperUser/ServerFault (или MSDN/TechNet, если на то пошло), где пользовательский интерфейс немного отличается, а модель данных больше или менее идентичны. Но когда модели и пользовательский интерфейс сильно отличаются (но наследуются от общей базы), я не уверен, как действовать дальше.

Меня меньше беспокоят операционные проблемы, так как мы, вероятно, будем запускать каждый сайт в отдельном домене и размещать их в отдельных базах данных. Я больше беспокоюсь о снижении долгосрочных расходов на обслуживание кода, повышении гибкости (например, легко добавлять новые функции в базу без разрыва производных приложений) и реализовать краткосрочную экономию средств на основе dev/test-cost, поскольку мы создаем наши 2-й, 3-й, 4-й и т. Д. Сайт.

Я ищу как для руководства и рекомендаций высокого уровня, так и для конкретных рекомендаций относительно того, как сделать это руководство реальным, используя современные методы ASP.NET MVC.

Я понимаю, что это очень общий вопрос, но для начала я ищу как руководство высокого уровня, так и конкретные советы-n-трюки о том, как применять это руководство с ASP.NET MVC, включая такие вещи, как :

• рекомендации, где расколоть базу /, полученные в различных проектах Visual Studio
• советы источником управления, чтобы избежать порождения
• советы схемы базы данных (FWIW, наши базы данных все small-- под 10K строк в таблице, так dev/test больше проблем, чем DB perf)
• советы по повторному использованию контроллеров/просмотров/и т. Д. соответствующие атрибутам «базовой» модели, особенно повторное использование пользовательского интерфейса для таких вещей, как формы «нового клиента», которые будут иметь сочетание базовых и производных атрибутов.

У кого-нибудь есть хороший совет для того, как архитектор приложения с несколькими арендаторами, как это?

Answer 1

Mike Hadlow идет в хорошую детализацию о том, как достичь этого:

http://mikehadlow.blogspot.com/2008/11/multi-tenancy-part-1-strategy.html

Answer 2

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

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

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

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

Последствия этого в том, что у нас есть структура проекта, которая состоит из базовой библиотеки, содержащей абстрактные классы, интерфейсы и классы полезности верхнего уровня, а также html-помощники, фильтры действий и т. Д. Затем у нас есть проекты mvc, которые содержат конкретные реализации базовых контроллеров, моделей и т. д., а также взгляды и мастер-страницы.

Самое сложное - обмен мнениями, и я не думаю, что мы все еще правильно разобрались. Хотя с MVC 2.0, содержащим Areas, я думаю, что это станет проблемой, но пока у меня не было хорошей игры. (см. сообщение Скотта Гу на 2.0: http://weblogs.asp.net/scottgu/archive/2009/07/31/asp-net-mvc-v2-preview-1-released.aspx) У меня есть POCed, похоже, что он будет работать, используя базовый MVC-проект, чтобы содержать общие представления, а затем расширять механизм просмотра по умолчанию для поиска этого проекта на веб-сервере при поиске для рендеринга (что довольно легко сделать). Области, хотя это гораздо более приятное решение.

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

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

Answer 3

Один из способов сделать это - использовать ветвление в системе управления источником.

Основная ветка предназначена для общей функциональности.Затем у вас есть ветвь для настройки и может объединять изменения в настройку или вернуться к основной ветке.

Answer 4

Вот что мы делаем, и это работает очень хорошо для примерно 8 сайтов в настоящее время.

• Определить базовый проект MVC для контроллеров, ViewModels, HttpApplication, маршруты и т.д. Это будет компилировать в DLL и скомпрометировать основную часть вашего сайта.

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

• На клиента создайте любые настраиваемые контроллеры, маршруты и т. Д., Которые вам понадобятся в проекте, который компилируется в другую dll.

• Также на каждого клиента воссоздайте все виды, сценарии, изображения, которые вы хотите использовать.

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

Второй способ получения всего рабочего заключается в том, чтобы ваше основное приложение загружало маршруты, контроллеры и т. Д. Из вашей конкретной сборки вашего клиента. Для этого я использую Managed Extensibility Framework (MEF), чтобы разоблачить один метод Register. Вызов этого метода на моем ассемблерном коде клиента регистрирует маршруты и любые другие специфические для клиента потребности.

Вот общий вид, что моя сайт структура папок выглядит, с SiteContent проверяемых просмотров первыхов:

- AppContent 
    - AppContent/Static 
    - AppContent/Static/Images 
    - AppContent/Static/Scripts 
    - AppContent/Static/Styles 
    - AppContent/Views 
    - AppContent/Views/Shared 

    - SiteContent 
    - SiteContent/Static 
    - SiteContent/Static/Images 
    - SiteContent/Static/Scripts 
    - SiteContent/Static/Styles 
    - SiteContent/Views 
    - SiteContent/Views/Shared 

    - web.config 
    - Global.asax 

У меня есть помощники, которые я могу использовать как SiteImage и AppImage для использования в моих взглядах. Кроме того, я делаю, чтобы каждый из моих клиентских сайтов использовал определенные имена для своих основных страниц, которые я никогда не определяю в своих настройках по умолчанию для AppContent.

Я понимаю, что это приблизительный обзор, но он работает достаточно хорошо для нас прямо сейчас.