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

Question

Мне было поручено переписать довольно большое веб-приложение для компании. Это приложение предоставляет определенный финансовый анализ / анализ рисков для 3 клиентов, которые у нас есть в настоящее время.

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

Скажите, что нашими клиентами являются 3 компании по производству оборудования:

• HackmansHardware
• LowesHardware
• FranksHardware

Аппаратное обеспечение Hackman может иметь немного другие потребности в анализе или запрашивать определенные специальные столбцы в наших отчетах. Аналогичным образом, Lowes Hardware может захотеть иметь немного иной защищенный доступ к своим страницам, чем другая компания в зависимости от пользователей.

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Передача данных для просмотра главных страниц:
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/

Answer 3

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

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

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

Answer 4

Ищите приложение "мультитенант". Здесь мультитенант на

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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