Могут ли доменные модели в базе данных быть устойчивым решением?

13

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

Больше всего меня беспокоит то, как наш основной разработчик базы данных (далее «Джон») хранит схему модели в базе данных! Мы делаем это, имея 3 "волшебных" стола; один для баз данных-схем, один для таблиц и один для столбцов.

Вставка записи в таблицу « Таблицы » создает (через триггер базы данных) фактическую соответствующую таблицу. Вставка строки в « Строке » -столы обновления родительской таблицы с этой строкой. Они, в свою очередь, читаются его самодельной C # -программой для генерации моделей C #, которые используются разработчиками frontend для контроллеров и для внешних целей.

Кроме того, большая часть разработки выполняется в соответствии с инфраструктурой ASP.NET MVC .

Я вижу пару недостатков с этим подходом:

  • Мы нуждаемся в нем, чтобы поддерживать ORM, и у него редко есть время, чтобы сделать это (безопасность работы хороша!)
  • Триггеры для таблиц «Столы» и «Строки» имеют недостатки. Они не поддерживают обновления таблиц, не проверяют ограничения или более «продвинутые» функции. Хотя мы, безусловно, могли бы их улучшить, я еще не уверен, стоит ли идти этим путем.
  • Хранение программной логики в базе данных кажется странным и ограничительным (хотя возможно расширить его модели с помощью C #).
  • Его генератор моделей C # должен запускаться вручную одним из 3 человек (среди которых я один), и он еще недостаточно зрел, чтобы быть включенным в автоматизированный процесс сборки.

Несколько человек предложили поэтапно внедрить настоящий и проверенный продукт, такой как Entity Framework , но он отклонил его, заявив, что сохранение бизнес-логики на уровне кода подходит только для небольших приложений и проектов начальной загрузки для стартапов.

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

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

krystah
источник
Доменные модели очень тесно связаны с доменным дизайном. Весь смысл доменного дизайна заключается в том, чтобы быть свободным от управляемого данными проекта, где данные (т.е. база данных) являются ядром приложения. Указанный подход и модели предметной области на самом деле не сочетаются друг с другом. При разработке в соответствии с практикой доменного управления вам не важно, откуда берутся данные, вы просто используете их и выполняете логику на бизнес-уровне.
Энди
Мне немного непонятно, что вы подразумеваете под «хранением программной логики в базе данных». Вы можете это уточнить?
Роберт Харви
Бизнес-логика в коде - это правильный путь. БД должна быть тупым хранилищем данных, ничего больше.
Энди
@ Энди, наверное, это зависит. Может быть, их администратор баз данных является центром команды, и он хранит всю бизнес-логику в базе данных, которая затем запрашивается тупыми хранимыми вызовами процедур, извлекает данные в POCO и т. Д. Это сомнительный подход, но я знаю команды, сохраняя большую часть бизнес-логики если не все это в БД.
Владислав Раструсный
@VladislavRastrusny Независимо от причины, сохранение бизнес-логики в БД - крайне плохой дизайн.
Энди

Ответы:

16

Вы описываете Внутреннюю Платформу.

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

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

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

Дальнейшее чтение
Проект «Vision», предостерегающий рассказ об эффекте внутренней платформы
(Вы можете пропустить преамбулу и начать чтение с подзаголовка «Представление Vision»)

Роберт Харви
источник
2
Интересное чтиво, я могу определенно рисовать анологии. Я все еще новичок и пока останусь зрителем, но я обязательно буду держать его под объективом. Спасибо за хороший ответ!
Крыста