Я просто смотрел предварительный просмотр сеанса в Aloha on Rails под названием «You're Doing it Wrong».Почему плохо использовать модели в качестве перечислений?
В коротком превью он упоминает использование моделей ActiveRecord в качестве перечислений (я полагаю, что он означает плагины, такие как enumerate_by). Мне кажется, это разумная идея, в чем проблемы? Это просто накладные расходы, требуемые дополнительными объектами?
Благодаря
Он немного гиперболический и идиоматический в своей презентации. Его точка звучит, однако.
Накладные расходы на разработку для статических данных в базу данных: вам нужно убедиться, что все миграции выполняются во всех средах (включая каждый раз, когда вы db: test: clone), вам нужно загрузить данных каждый раз, когда вы работаете с вашим кодом (например, даже в irb), вы можете столкнуться с проблемами порядка загрузки. Короче говоря, это не бесплатно, и мы не хотим нести ненужные затраты на разработку и поддержку.
Однако, это может быть полезно для этого. Данные могут быть разделены между кодом, написанным на разных языках; код может быть сложным и требует дорогостоящего цикла тестирования перед каждым развертыванием; вы можете создать базу данных с ограничениями данных; вы можете иметь обширные или структурированные метаданные, которые вы хотите связать с перечислением; и так далее.
Эти условия не являются общими. Для большинства перечислений достаточно назвать именованные константы, хэш или даже просто условное использование символов.
По его словам, его статического перечисления он имеет проблемы с. Зачем нужен запрос базы данных для некоторых статических данных, которые можно хранить в именованных константах?
Кроме того, некоторые разработчики кодируют будущее. Его о кодировании к требованиям на данный момент, сохраняя дизайн закрытым для модификации и открытым для расширения, если вообще это требование распространяется в будущем. В противном случае вы будете тратить время, усилия и, в конечном счете, деньги на то, чего клиент действительно не просил. Масштабируемый дизайн - это одно, а дизайн для будущих потребностей - другое. В то время как первая может быть расширена до более поздней, если это необходимо, позже на самом деле не требуется в этот момент времени.