Насколько плохо хранить имена классов и сборок в базе данных?

Question

Вкратце:

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

Полное объяснение:

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

Чтобы найти и запустить задание, загрузочный стриппер имеет файл app.config, который содержит имя задания, а также имя сборки и имя класса, которое его определяет.

Меня попросили переместить имя сборки и имя класса в базу данных, чтобы мы могли избавиться от файла app.config. (Причина в том, чтобы хранить всю конфигурацию в одном месте - базе данных.)

Однако загрузчик является единственным кодом, который запускает задание, и эта информация о «конфигурации» никогда не будет изменена после развертывания. Я думаю, что размещение такой информации в базе данных дает слою данных слишком много информации о вышеперечисленных слоях и будет мешать рефакторингу и обслуживанию. Однако я знаю, что Windows Workflow Foundation делает именно это, и, возможно, я ошибаюсь, считая это плохой практикой?

Edit:

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

Answer 1

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

Я бы не считал данные, хранящиеся в базе данных, частью уровня данных.

Answer 2

Чтобы обойти это немного, с примером, который оправдывает вашу реализацию:

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

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

Answer 3

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

Уровень модели / данных на самом деле ничего не «знает», это просто хранилище для хранения того, что вы хотите.

Answer 4

Я не вижу проблем с этим, хотя я не слышал о базе данных как об этом хранилище.

Answer 5

Конечно, я делаю то же самое для меню в нашем приложении.

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

Answer 6

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

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

Вы разработчик, так что это ваш призыв, не так ли? Если нет, то это позор, но проясните, каково ваше мнение, и попробуйте количественно оценить затраты (честным методом), и если ваш путь будет дешевле, вы, вероятно, добьетесь своего. Однако сколько стоит спорить об этом?

PS Я голосую за парня, который спросил, куда идет строка подключения к БД!