Настройки клиента

Question

У нас есть продукт с базой установки около 50, более 50% этих установок имеют настройки в коде для бизнес-логики, и в настоящее время это делается с помощью огромных операторов IF и Switch.

В настоящее время мы обновляем код до .NET 3.5 и хотели бы обработать настройки более управляемым способом. На данный момент мы можем думать только о том, чтобы придерживаться больших операторов IF и Switch или иметь отдельные файлы в Source Code Control для каждого клиента, что опять-таки не кажется идеальным.

Есть ли приемлемый способ обработки большого количества настроек в кодовой базе?

Answer 1

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

Answer 2

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

После этого вы можете иметь репозиторий для каждого клиента, содержащий файлы конфигурации (и, возможно, ресурсы, такие как логотипы и / или пользовательские скрипты), а также репозиторий для основного приложения.

Для данной версии клиента ваша система сборки затем автоматически собирает приложение и хранилище клиента и создает пользовательскую версию.

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

Answer 3

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

Например, у вас может быть класс Transfer в BaseLibrary, а затем у вас может быть класс LoggingTransfer, расширяющий Transfer в библиотеке CustomerX, которая содержит только код, который настраивает базовую функциональность.