Разработка API / Framework: настройка режимов / сред (таких как режим разработки и т. Д.)

Question

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

---

Немного предыстории и пояснений: У нас есть собственный фреймворк, который имеет несколько режимов:

• режим приложения: dev, test, prod.Установите в конфигурационном файле.
• режим "киоска": включен, выключен.Специфично для приложения, переопределяется в коде.
• режим отладки во время выполнения: если установлен режим приложения dev и задан определенный параметр URL.
• специфические флаги отладки: отображать границы, показывать информацию о производительности и т. Д.,устанавливается приложением.
• будущие режимы ...

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

Проблема состоит в том, что эти режимы управляются через один класс 'god' в платформе, которая читает файл конфигурации, параметры URL, а также имеет виртуальные свойства, которые могут быть переопределенычтобы указать режим 'киоска'.

Так что у этого класса бога есть много ссылок на сервисы, которые я могу вытащить и определить в конструкторе для внедрения зависимости.Однако проверки для различных режимов распространяются по всей кодовой базе (если режим dev ... или если режим киоска).Очень похоже на то, как имеет смысл обращаться к библиотеке журналов с помощью статических методов, мне интересно, имеет ли смысл иметь несколько статических методов, которые приложение будет устанавливать в событии ApplicationStart asp.net.

Один изЦелью этой перестановки кода является помощь в модульном тестировании.Что касается режимов, необходимо протестировать только режимы киосков и некиосков, так как режимы отладки предназначены только для разработчиков.

Опции:

1. Синглтон-класс / статический метод настройкирежимы, вызываемые при запуске приложения
2. Имеют конкретные объекты dev / kiosk и передают их как зависимости, настроенные при запуске.Например, вместо MailService, будут также DevMailService и KioskMailService.Это будет означать много дополнительной работы для начала.
3. Классы, которые требуют знаний о режиме dev / kiosk или опциях отладки, имеют свойства для включения / выключения.Пользователь должен проверить, правильно ли он / она настраивает их все.(разумные значения по умолчанию для режима отладки)
4. Или режимы устанавливаются в конструкторе классов как логические параметры.(вероятно, более полезно для режима киоска, который должен быть установлен правильно)
5. Специальный "класс обслуживания режима", который передается через конструктор для всех классов, которые требуют знания о режиме.
6. Aспециальный класс обслуживания режима отладки, который может быть установлен через свойства при необходимости, по умолчанию установлен на нулевой объект.
7. Комбинация вариантов.

Я склонялся к свойствам для параметров отладки и флагов (3), к параметрам конструктора для установки режима киоска (4), но новый код был написан с определеннымКиоск и не Киоск классы (2).Не совсем уверен, как справиться с обработкой режима отладки, установленного через параметры URL, хотя, возможно, используя службу отладки, установленную через свойство с нулевым объектом по умолчанию.(6) * * 1 044

Answer 1

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

Для одного из моих собственных проектов я также решил не идти на архитектурные изменения просто потому, что мы потеряли бы доверие к системе. Иногда лучше знать , что не работает, вместо того, чтобы сильно путаться, угадывая , как это сделать правильно.