Почему плохо использовать модели в качестве перечислений?

Question

Я просто смотрел превью сеанса в Aloha на Rails под названием " Вы делаете это неправильно ".

В кратком предварительном просмотре он упоминает использование моделей ActiveRecord в качестве перечислений (я предполагаю, что он имеет в виду плагины, подобные enumerate_by ). Это кажется мне разумной идеей, в чем проблемы? Это просто накладные расходы, необходимые для дополнительных объектов?

Спасибо

Answer 1

Он немного гиперболичен и идиоматичен в своей презентации. Его точка зрения, тем не менее.

Сложность разработки заключается в размещении статических данных в базе данных: вам необходимо убедиться, что все миграции выполняются во всех средах (включая каждый раз, когда вы выполняете db: test: clone), вам необходимо загрузить данные каждый раз, когда вы работаете с вашим кодом (например, даже в irb), вы можете столкнуться с проблемами порядка загрузки. Короче говоря, это не бесплатно, и мы не хотим нести ненужные расходы на разработку и поддержку.

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

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

Answer 2

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

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