Блог

Недавно я начал работать в этой компании, и они показали мне эту «структуру», которую они используют в компании для проекта. И главная цель состоит в том, чтобы делать все из базы данных, потому что таким образом ее можно будет изменить позже, не касаясь кода, только базу данных, которая «проще». Таким образом, это будет выглядеть следующим образом:

 |id |component_id |default  |read_only|visible|form_id|
|---|-------------|---------|---------|-------|-------|
|1  |2            |now()   4|false    |true   |3      |
|2  |1            |null     |false    |true   |4      |
|3  |5            |null     |true     |true   |1      |
 

component_id Переход к таблице компонентов, где они определяют каждое поле, например, выбор даты, ввод, выбор… И так далее, и form_id он переходит в другую таблицу, где находятся разные формы в приложении, такие как регистрация, вход в систему, add_order… Так далее.

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

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

Мы используем Dart/Flutter в интерфейсе, и мне нравятся строгие типизированные языки, но это удаляет строгий тип для предположения, какое значение в бд мы получаем, и у нас есть огромный файл с инструкциями switch, проверяющими, какой компонент должен его отображать и применять все остальные значения.

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

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

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

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

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