Как Вы разрабатываете веб-приложение, которое должно быть настроено для каждого нового клиента?

Сколько потенциальных клиентов вы ожидаете? Если ответ - 2 новых клиента в год, ваше решение будет отличаться от того, если вы скажете 200 новых клиентов в год.

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

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

Мне придется не согласиться с некоторыми подходами, описывающими наследование от общего базового контроллера и т. Д., Потому что создание подклассов само по себе не сработает. Вы будете добавлять производные классы для каждого клиента, и это станет кошмаром для обслуживания, если у вас будет больше, чем просто несколько клиентов. Кроме того, хотя MasterPage будет использоваться в некоторой степени, если ваши клиенты хотят внести вклад в внешний вид своего сайта, многие вещи, такие как цвета, стили и т. Д., Должны будут управляться данными.

Идея портала довольно хороша, но если у вас много логики пользовательского домена, которая будет отличаться от клиента к клиенту, это также быстро станет проблемой. Если для некоторых клиентов нужно просто скрыть некоторые страницы, то идея портала - неплохое предложение. Имейте в виду, что если вы используете предпроизводственные среды, такие сайты портала, как DotNetNuke, может быть трудно развернуть из одной среды в другую, если вы не ознакомитесь с их схемой. Кроме того, такие сайты, как DotNetNuke, не написаны на MVC, поэтому применение любых методов разработки, основанных на тестировании, будет намного сложнее, чем начинать с нуля.

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

Надеюсь, это поможет.

Вам нужен «Веб-портал».

Существует хорошая информация о том, как создавать веб-порталы в ASP.NET, которая может дать вам некоторые идеи о том, как это сделать с помощью MVC. В частности, существует портал DropThings и сопутствующая книга Создание портала Web 2.0 с помощью ASP.NET 3.5 . Возможно, вы сможете адаптировать большую часть или все его идеи к ASP.NET MVC.

Azure основан на Windows Server 2008 и IIS7. Это означает, что вам нужно заполнить часть system.webServer файла web.config.

Образец файла, включенный в исходный код elmah, содержит детали, которые вам нужно вставить.

<system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  <modules>
    <remove name="ScriptModule" />
    <add name="ScriptModule" preCondition="managedHandler" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
  </modules>
  <handlers>
    <remove name="WebServiceHandlerFactory-Integrated"/>
    <remove name="ScriptHandlerFactory" />
    <remove name="ScriptHandlerFactoryAppServices" />
    <remove name="ScriptResource" />
    <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode"
         type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode"
         type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <add name="elmah" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
  </handlers>
</system.webServer>

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

РЕДАКТИРОВАТЬ: Больше не требуется, так как теперь он включен по умолчанию: Здесь мультитенант на so

Или здесь Блог Барта

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

Используйте XML для описания схемы для каждый магазин. Создайте инструмент, который генерирует схему БД на основе XML. Кодируйте свои отчеты так, чтобы анализировать XML и определять, какие столбцы отображать. Продолжайте до тошноты.

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

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

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

Передача данных в представление. Просмотр главных страниц:
http://www.asp.net/learn/MVC/tutorial-13-cs.aspx

Также обратите внимание на следующую ссылку, которая объясняет, как реализовать частичные представления и субконтроллеры в ASP.NET MVC:

Частичные запросы в ASP.NET MVC
http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/

Настройка на уровне данных всегда является сложной задачей. Начните с тщательного анализа того, что именно отличается от одного клиента к другому. Затем поищите способы создать единый дизайн данных, который инкапсулирует варианты. Это может быть сложно, но мы действительно того стоим. Если вы можете попытаться придумать, как вы могли бы создать дизайн, который был бы достаточно гибким для потребностей будущих клиентов (да, это может быть связано с хрустальным шаром).

С архитектурной точки зрения, рассмотрите возможность использования абстрактного шаблона фабрики в уровень доступа к данным. Не зная подробностей требований или степени различия от одного клиента к другому, я не уверен, насколько это применимо, но я ' В прошлом мы успешно использовали этот шаблон для учета довольно широких различий в формате и структуре источников данных, которые необходимо было доставить на общий уровень обработки / представления. Это позволит вам создавать компоненты уровня данных, которые подключаются непосредственно к внешнему интерфейсу системы.

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

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

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

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

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

Обратите внимание, что я использую здесь C # и IronPython в качестве примеров - вы можете использовать любую комбинацию двух языков. Однако я думаю, что между ними должно быть существенное различие в синтаксисе, чтобы границы были четкими.

но когда вы думаете о коде Python как о прославленной конфигурации для вашего приложения, это может быть не так уж и плохо. Поскольку настройки в Python взламываются для конкретных клиентов, которые превращаются в концепции многократного использования, я бы переработал их в C #, добавил их в структуру и удалил настройки.

Обратите внимание, что я использую здесь C # и IronPython в качестве примеров - вы можете использовать любую комбинацию двух языков. Однако я думаю, что между ними должно быть существенное различие в синтаксисе, чтобы границы были четкими.

но когда вы думаете о коде Python как о прославленной конфигурации для вашего приложения, это может быть не так уж и плохо. Поскольку настройки в Python взламываются для конкретных клиентов, которые превращаются в концепции многократного использования, я бы переработал их в C #, добавил их в структуру и удалил настройки.

Обратите внимание, что я использую здесь C # и IronPython в качестве примеров - вы можете использовать любую комбинацию двух языков. Однако я думаю, что между ними должно быть существенное различие в синтаксисе, чтобы границы были четкими.

m используя C # и IronPython в качестве примеров здесь - вы можете использовать любую комбинацию двух языков. Однако я думаю, что между ними должно быть существенное различие в синтаксисе, чтобы границы были четкими.

m используя C # и IronPython в качестве примеров здесь - вы можете использовать любую комбинацию двух языков. Однако я думаю, что между ними должно быть существенное различие в синтаксисе, чтобы границы были четкими.