Комментарии 22
Интересно, но вот только непонятно причём тут DRY. По сути он относится только к
а всё остальное собственно к «не повторяй себя» отношения имеет мало
# lib/models/validations.rb
module Models
module Validations
# общий модуль c валидациями для нескольких моделей
end
end
а всё остальное собственно к «не повторяй себя» отношения имеет мало
Влияет ли это как-то на скорость работы приложения, где каждая копейка дорога? Насколько я знаю все это инклудится на этапе загрузки приложения, а на этапе запроса уже не играет никакой роли, но хотелось бы подтверждения.
Ну, в общем случае так оно и есть.
habrahabr.ru/blogs/ror/125822/#comment_4142353 этот комент сюда предназначался :)
Такой подход удлинняет цепочку наследования и фактически может увеличить время поиска метода при его вызове. Но не думаю, что сколько-нибудь существенно.
Спасибо, буду пользовать. Про концерн не слышал даже…
Видел очень интересный доклад на RailsConf 2011 близкий к поднимаемой теме Fat Models Aren't Enough.
там где каждая копейка дорога разве используют RoR?
Копейки разные бывают.
ТОЛЬКО АССЕМБЛЕР!!! ТОЛЬКО ХАРДКОР!!!
Почему нет? Сервер стоит гораздо дешевле, чем найм программистов, при этом, хотя Rail-программист стоит дороже, более выгодно использовать Rails, нежели PHP, поскольку скорость разработки значительно выше. Ну а если возникнут проблемыы с производительностью, то всегда можно переписать, например на Java (сомневаюсь, что вы будете писать Twitter).
Отличный пример того как надо рефакторить код моделей. Я почему-то раньше думал, что данный подход используется только при написании больших гемов.
Буду пользоваться, исправляться. Спасибо большое!
Буду пользоваться, исправляться. Спасибо большое!
Открыл статья в сладкой надеждле узнать что-то новенькое, а прочитал о том, как инклюдить модули… Мда… Но плюсик поставил, сообщесту нужны статьи всякие и разные.
Вот тут про это хорошо написано: wearestac.com/blog/2011/05/organise_your_models
А я написал простенький генератор для генерации таких вот штук: github.com/ognevsky/xf-generators. Там, правда, нужно код почистить, а то выложил что сразу получилось и забил ;/
Пользоваться так: rails g xf:concern user friendship (по аналогии со статьей по ссылке выше). Создаются все необходимые файлы (в тч файл спека) с заготовленным текстом.
А я написал простенький генератор для генерации таких вот штук: github.com/ognevsky/xf-generators. Там, правда, нужно код почистить, а то выложил что сразу получилось и забил ;/
Пользоваться так: rails g xf:concern user friendship (по аналогии со статьей по ссылке выше). Создаются все необходимые файлы (в тч файл спека) с заготовленным текстом.
Про Concern полезный раздел, я про него сам узнал только с месяц назад.
Но все же DRY заключается не в размазывании кода по модулям.
Если имеем два класса с одинаковым кодом, то да, можно и модули применить.
Хотя даже в этом случае вижу минимум два варианта отDRYить классы:
* унаследовать от одного класса, все общее перенести туда
* общее вынести в модуль и инклюдить его
Но все же DRY заключается не в размазывании кода по модулям.
Если имеем два класса с одинаковым кодом, то да, можно и модули применить.
Хотя даже в этом случае вижу минимум два варианта отDRYить классы:
* унаследовать от одного класса, все общее перенести туда
* общее вынести в модуль и инклюдить его
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как DRYить модели