2010-01-29 3 views
1

Вы когда-нибудь делали это?Два класса модели - одна таблица базы данных

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

У меня также есть AssignmentController, который предоставляет некоторые представления и функциональные возможности для лица, которому назначено задание. AssignmentController использует Task.find для получения задачи и является тем же объектом, что и Задача, - это просто обновляется Assignee и только правопреемнику доступно только несколько столбцов. В этом случае я хотел скрыть некоторый пользовательский интерфейс, изменить макет, чтобы он соответствовал бизнесу, и иерархия не имела значения для правопреемника задачи.

То, что я собираюсь сделать, это создать модель задачи и модель присваивания, которые указывают на одну и ту же таблицу (таблица задач). Я не понимаю, почему я не должен этого делать. Это позволило бы мне уменьшить класс модели Assignment и изолировать методы, которые используются только Task. Насколько я могу судить, это также сделает большую часть кода чище кода.

Я не вижу много об этом шаблоне при поиске в Интернете. Любые мнения об этом?

Цените свои мысли ...

+0

Я все еще исследую это. Я просто модель и попробовал ее в скрипте/консоли, и, похоже, он работает нормально. Вы можете даже получить доступ к «Задаче», если это необходимо, из Присвоения. has_one: task,: foreign_key =>: id В конечном итоге это позволило бы мне иметь «бизнес» метод (например) для каждой модели, который указывает на другой бизнес. Одна ожидаемая проблема - любые полиморфные элементы в Задаче (например, фотографии) не были бы в задании, но могли бы быть доступны через Задачу, если это необходимо. – Swards

ответ

1

Если я правильно понял, вы хотите, чтобы подклассы таблицы :) Хорошая идея, не понимаю, почему это не будет работать ... set_table_name «задачи» будет делать это , или просто подклассифицировать модель задачи. Но в обоих случаях вы получите в неприятности с ассоциациями, вы должны будете определить belongs_to: задачи и BELONGS_TO: назначение для любого has_many ассоциации, то там вы хотите сделать это правильно ...

Edit: На самом деле забудьте, что я сказал :) http://railscasts.com/episodes/154-polymorphic-association

0

У вас должна быть таблица соединений между Assignee и Tasks. Ваше предложение может привести к тому, что ваши взгляды будут замусорены с заявлениями о погоде или нет у вас правопреемник или задача. Если вы обнаружите, что используете одни и те же фрагменты html между ними, вы можете просто использовать частичные.

Кроме того, ваше предложение несколько не соответствует нормализации базы данных. Нормализация - это не то, что вам нужно сегодня, а то, что вам может понадобиться завтра. Если у вас больше нет информации о правопреемнике, чем имя пользователя, вполне возможно, что для обеих моделей может быть одинаковая таблица (вид). Но как насчет позже, когда вы хотите получить дополнительную информацию о Assignees?

+0

Я согласен, что это странно - но в моем случае мне не нужен столбец типа (в STI), и я просто хочу изменить несколько методов (например, бизнес, который «владеет» им). Все остальное успокаивается. Он также играет гораздо приятнее с Declarative Auth - плагином, который использует имя и тип переменной по умолчанию (@ assignignment, Assignment). У меня было свойство belongs_to, has_one, но это было больше, чем мне нужно. Я создал задание с каждой задачей. В целом - это просто удобство, чтобы сохранить спокойные контроллеры. Спасибо за ваши мысли. Хорошо знать, какие правила я нарушаю. – Swards

Смежные вопросы