Альтернатива наследованию одной таблицы Rails (STI)?

У меня есть модель и таблица, которые, как мне кажется, идеально подходят для STI. Моя таблица называется Finances и имеет два типа: Доходы и Расходы. Помимо type есть еще три столбца: description, amount и date.

Я очень нервничаю, используя STI в Rails, так как это требует некоторого взлома. Я слишком новичок в Rails, чтобы разбирать код. Хотя это работает, я не понимаю этого. Это кажется опасным.

Мой вопрос: как настроить модель, контроллер и представление, если я НЕ использую STI? Любые рекомендации по группировке элементов в моей модели? Или мне просто сделать Finances.where("type = 'Income'") перед настройкой представления?

Изменить: я сделал суть, чтобы показать код, с которым я работаю. Когда я запускаю его, я получаю сообщение об ошибке:

undefined method `incomes_path' for #<#<Class:0x007fbc95f60b40>:0x007fbc93883220>

ruby-on-rails sti
person Casey    schedule 05.03.2013    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

Если, с другой стороны, вы решите НЕ использовать STI, у вас есть выбор: использовать
(а) полностью отдельные модели с собственными таблицами, что приведет к множеству дублированного кода, или
(б) создать собственное "подобное ИППП" поведение вручную. Второй вариант, по крайней мере, может быть интересен, чтобы узнать больше о Rails.

Например, в вашей модели Finances вы должны определить область действия incomes, например

scope :incomes, where(:type => 'Income')

то вы можете сделать Finances.incomes.

Затем, если у вас есть методы, которые применяются только к одному из типов, вы должны проверить, что все записи действительно относятся к нужному типу.

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

person kr1    schedule 05.03.2013
comment
Хорошо, вы убедили меня продолжать продвигать STI. Я думаю, что у меня есть часть модели, но я смущен при использовании ее в контроллере или представлении. Если вы не возражаете, я хотел бы опубликовать код на Github позже сегодня, чтобы вы могли увидеть, где я ошибаюсь. - person Casey; 05.03.2013
comment
Эй, извините за пост про зомби, но что вы думаете о полиморфном наследовании @kr1? Просто для справки, я делаю приложение с врачами и больницами, двумя отдельными группами пользователей. Вы использовали их или STI по-прежнему остается путем Rails? - person Daryll Santos; 04.04.2014

arrow_upward
0
arrow_downward

STI лучше всего подходит, если вы используете такую ​​структуру наследования. Вам действительно не нужно использовать Finances.where("type = 'Income'"). Вы можете просто использовать Income.all. посмотрите эти сообщения, если они вам помогут. http://www.therailworld.com/posts/18-Single-Table-Inheritance-with-Rails http://juixe.com/techknow/index.php/2006/06/03/rails-single-table-inheritance/

person Ramiz Raja    schedule 05.03.2013
comment
А как насчет использования form_for? henrik.nyh.se/2012/08/rails-sti -and-form-for В этой статье я обнаружил, что мне нужно использовать object.becomes, чтобы он работал с STI. В конце статьи автор говорит, что этот метод хрупок, поэтому обязательно протестируйте его. - person Casey; 05.03.2013