Лучшие практики для проектирования моделей в Ruby on Rails

Question

В руководствах по RoR для работы ORM предусмотрена одна модель на таблицу. Моя схема БД содержит около 70 таблиц, разделенных концептуально на 5 групп функциональности. (например, любая таблица находится в одной и только одной функциональной группе, а отношения между таблицами разных групп сведены к минимуму.) Итак: я должен проектировать модель для концептуальной группы, или я должен просто иметь 70 моделей Rails и оставить группировку «концептуальной»? Спасибо!

Answer 1

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

Answer 2

Я расскажу об этом в одном из моих больших приложений, просто убедившись, что таблицы / модели концептуально сгруппированы по имени (почти с соотношением 1: 1 к модели таблицы). Пример:

events
event_types
event_groups
event_attendees
etc...

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

Answer 3

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

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

Например, вы могли бы иметь:

app/models/admin/user.rb
app/models/admin/group.rb

для моделей Admin :: Пользователь и Администратор :: Группа и

app/models/publishing/article.rb
app/models/publishing/comment.rb

для издательства :: Статьи и издательства :: Комментарий

И так далее ...

Answer 4

Прежде чем приступить к созданию 70 моделей, рассмотрите этот вопрос, чтобы помочь вам решить:

Будет ли каждая из ваших таблиц рассматриваться как "объект", например таблица "cars", или некоторые таблицы содержат только информацию об отношениях, например все столбцы внешнего ключа?

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

Answer 5

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

Связаны ли таблицы с каким-то типом наследования или они могут быть? Rails может делать ограниченную форму наследования. Поиск наследования одной таблицы (STI).

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

Answer 6

Как уже упоминалось, трудно дать достойный совет, не зная схемы вашей базы данных и т. Д., Однако я бы склонялся к созданию моделей более 70 (по одной для каждой из ваших таблиц).

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

Вам не нужно создавать контроллер + представления для каждой модели (как ответил srboisvert). Вам нужен только контроллер для каждого ресурса (который, как я ожидаю, будет намного меньше 70, вероятно, всего 10 или 15, судя по вашему описанию).

Answer 7

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

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

app/models/admin/base.rb - module Admin::Base, included by all other Admin::xxx
app/models/admin/user.rb - class Admin::User, includes Admin::Base
app/models/admin/group.rb - class Admin::Group, includes Admin::Base