Архитектура для спутниковых частей более крупного приложения

Question

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

Теперь мы хотим реализовать поддержку отслеживания разрозненных точек данных и процессов, которые различаются в разных штатах, сохраняя при этом основную национально-ориентированную систему. Как это:

Стек, с которым я работаю, - это ASP.Net и SQL Server 2008. Национальное приложение - довольно простая вещь для веб-форм. Его уровень доступа к данным является оболочкой репозитория вокруг сущностей LINQ to SQL и datacontext. В настоящее время существует мало бизнес-логики, кроме операций CRUD, но их будет больше, когда будут представлены сложности каждого состояния.

Итак, как заставить осколки спутников ...

• Просто начните глядеть на функциональность и преследуйте большой шарик грязи
• Создание серии спутниковых приложений, которые повторно используют уровень доступа к данным, но в остальном являются автономными
• Инвестируйте (деньги и / или время) в механизм правил (в стиле Windows Workflow) и выделяйте уникальные биты для каждого состояния в виде отдельных наборов правил
• Инвестируйте (время) в инфраструктуру плагинов в виде MEF и реализуйте функциональность каждого состояния в виде плагина
• Что-то еще

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

У меня нет опыта работы с MEF или WF, поэтому мой вопрос в значительной степени состоит в том, является ли моя проблема типом проблемы, на которую она направлена. Они оба звучат так же, как и в случае с рекламой, но могут оказаться квадратным колышком для круглого отверстия.

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

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

Answer 1

Начните с шаблона проектирования Strategy , который в основном позволяет вам наметить «заполнитель», который будет заменен конкретными классами во время выполнения.

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

IStateStrategy stateStrategy = StateSelector.GetStateStrategy("TX"); //State id from db, of course...
stateStrategy.Process(nationalData);

Конечно, каждая из этих стратегий должна использовать существующий слой данных и т. Д.

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

Answer 2

Просто мысль: что бы вы ни делали, сначала полностью кодируйте 3 состояния (с 2 вы все еще испытываете желание повторить один и тот же код, а чем больше, тем больше времени занимает, если вы решите изменить дизайн).

Должен признать, я совершенно не осведомлен о правилах или WF. Но разве нельзя было бы просто иметь один большой глупый файл включения ASP.Net с инструкциями для состояний, отделенных от основной логики, без какого-либо дополнительного языка / программы?

Редактировать: Или это просто тот факт, что каждое государство имеет в кавычках совершенно разные функциональные возможности, а не только некоторые биты?