Как DRYить модели

[@VolCh]

Интересно, но вот только непонятно причём тут DRY. По сути он относится только к

# lib/models/validations.rb
module Models
  module Validations
    # общий модуль c валидациями для нескольких моделей
  end
end

а всё остальное собственно к «не повторяй себя» отношения имеет мало

[@rwz]

Ну вообще да, правильное замечание. Наверное, стоило как-то отметить, что где DRY, там, обычно, и модульность со структурированностью.

[@asci]

Ага, остальное — KISS и рефакторинг)

[@SmartBye]

Влияет ли это как-то на скорость работы приложения, где каждая копейка дорога? Насколько я знаю все это инклудится на этапе загрузки приложения, а на этапе запроса уже не играет никакой роли, но хотелось бы подтверждения.

[@rwz]

Ну, в общем случае так оно и есть.

[@f0rk]

habrahabr.ru/blogs/ror/125822/#comment_4142353 этот комент сюда предназначался :)

[@getElementById]

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

[@fuCtor]

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

[@asci]

Спасибо, буду пользовать. Про концерн не слышал даже…

[@aiperon]

Видел очень интересный доклад на RailsConf 2011 близкий к поднимаемой теме Fat Models Aren't Enough.

[@f0rk]

Клевый доклад кстати, мне нравится такой подход, я на симфони пишу щас (но вобщем какая разница :)) и когда фигачишь в модели метод с запросом состоящим из кучи джойнов к другим моделям, думается иногда: «а какого черта я пишу это именно в этом классе?». Презентеры — клевый петтерн буду думать… :)

[@f0rk]

там где каждая копейка дорога разве используют RoR?

[@SmartBye]

Копейки разные бывают.

[@Aux]

ТОЛЬКО АССЕМБЛЕР!!! ТОЛЬКО ХАРДКОР!!!

[@egoholic]

Почему нет? Сервер стоит гораздо дешевле, чем найм программистов, при этом, хотя Rail-программист стоит дороже, более выгодно использовать Rails, нежели PHP, поскольку скорость разработки значительно выше. Ну а если возникнут проблемыы с производительностью, то всегда можно переписать, например на Java (сомневаюсь, что вы будете писать Twitter).

[@Litiy]

Отличный пример того как надо рефакторить код моделей. Я почему-то раньше думал, что данный подход используется только при написании больших гемов.

Буду пользоваться, исправляться. Спасибо большое!

[@egoholic]

Открыл статья в сладкой надеждле узнать что-то новенькое, а прочитал о том, как инклюдить модули… Мда… Но плюсик поставил, сообщесту нужны статьи всякие и разные.

[@ognevsky]

Вот тут про это хорошо написано: wearestac.com/blog/2011/05/organise_your_models
А я написал простенький генератор для генерации таких вот штук: github.com/ognevsky/xf-generators. Там, правда, нужно код почистить, а то выложил что сразу получилось и забил ;/

Пользоваться так: rails g xf:concern user friendship (по аналогии со статьей по ссылке выше). Создаются все необходимые файлы (в тч файл спека) с заготовленным текстом.

[@UseRifle]

В ссылке на гитхаб точка лишняя :)

[@ognevsky]

Ну это парсер же лох :) Как же без точки и конце предложения можно жить?

[@UseRifle]

Про Concern полезный раздел, я про него сам узнал только с месяц назад.

Но все же DRY заключается не в размазывании кода по модулям.

Если имеем два класса с одинаковым кодом, то да, можно и модули применить.

Хотя даже в этом случае вижу минимум два варианта отDRYить классы:
* унаследовать от одного класса, все общее перенести туда
* общее вынести в модуль и инклюдить его

[@rwz]

Наследование в случае рельсовых моделей хреново выглядит. Там STI по-умолчанию пытается включиться.