Архитектура сайта - контроль/загрузка объектов на основе конфигурации?

Question

Я создаю сайт, который должен немного измениться на определенных рынках. Например, на британском рынке форма регистрации должна выполнять проверку адреса (уже есть эта работа), а на сайте в Бельгии нам нужно проверить человека с веб-службой (уже есть эта работа). В противном случае функции регистрации в основном одинаковы. У нас эти два сайта работают независимо, но мы хотели бы объединить их в одну кодовую базу, которая может поддерживать любую опцию на основе config.

Моя первоначальная мысль заключалась в том, чтобы использовать значение конфигурации, чтобы сказать «Это сайт в Великобритании» или «Это сайт в Бельгии» и отобразить страницы на основе этой настройки.

Идеи:

• Dependency Injection для загрузки элементов управления динамически на основе конфигурации
• Factory шаблон для использования Reflection/Активатор и загрузки динамически на основе конфигурации
• Config трансформирует для загрузки различных пользовательских элементов управления, установив tagname/tagprefix
• Другое?

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

Answer 1

Я бы порекомендовал сохранить его максимально простым и минимальным.

Просто создайте что-то вроде IPersonValidator, которое имеет метод .Validate(PersonDetails) и возвращает массив ошибок.

Edit:

На стороне конфигурации, вы можете создать раздел пользовательской конфигурации следующей структуры:

<DomainSpecificSettings> 
<Key name="validator"> 
    <Value domain="www.yoursite.co.uk" value="firstValidator" /> 
    <Value domain="www.yoursite.de" value="secondsValidator" /> 
</Key> 
</DomainSpecificSettings> 

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

ValidatorsStore.GetValidator(string configValue).Validate(PersonDetails). 

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

Answer 2

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

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

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

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