Пример жирной модели Rails, это правильный образ мышления?

Question

Если у меня есть две таблицы в базе данных User и Userinfo (разделены для целей normalization ), я генерирую две модели User, UserInfo и использую их как обычно через отношения.

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

Имеет ли смысл создать третью модель (модель без поддержки базы данных), чтобы справиться со всем этим и создать / сохранить с помощью двух других моделей? или я должен держать это в контроллере?

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

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

Answer 1

Звучит так, как будто вы нормализуете (сводите к минимуму избыточность), а не отменяете нормализацию.

Я не знаю ваше приложение, поэтому, пожалуйста, примите это как нечто, что следует рассмотреть, а не как рекомендуемый лучший метод:Как правило, в такой ситуации скрывается информация пользователя за пользователем, так что пользователь является единственной частью приложения, которая даже знает, что существует информация пользователя.Это делает вещи простыми и последовательными и СУХОМИ для других клиентов кода (контроллеры, другие модели и вы при взаимодействии с ним в консоли).

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

Answer 2

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

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

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