воскресенье, 3 июля 2011 г.

Re: Мышление моделями и данными - в чем разница?

там есть несколько ошибок по тесту забывать нужно не о моделях а об
sql, и забыл запятую здесь
scope :active, where(:is_active => true, :is_banned => false)
может еще пара опечаток - извиняйте, торопился.
On 4 июл, 09:56, Лев Черемухин <nir0pi...@gmail.com> wrote:
> модель может быть необязательно с таблицей.
> вообще, когда вы переходите от таблиц и sql к моделям, нужно как-бы
> забывать о последних, теперь они для вас всего-лишь хранилище данных,
> и неважно даже, какая СУБД за рельсами стоит. это могут быть mysql,
> postgresql, oracle, sqlite и т.д.
> модель во многом сама заботится о своей таблице - придумывает ей
> название, создает поля. достаточно правильно её сгенерировать:
> rails g model person name:string biography:text
> создаст файл миграции, который можно запустить с помощью rake
> db:migrate
> будет создана таблица, названная people (множественное число от
> person), в которой помимо заданных полей имя и биография будут
> автоматически созданы id, created_at, updated_at, который будут при
> каждом создании/сохранении объекта автоматически задаваться, то есть
> вы, к примеру, не можете менять id объекта, потому что это зашито в
> рельсы (хотя есть и обходные пути, вам уже известные), и логика и
> философия говорят, что менять эти поля не нужно
> ну это пока сомнительный профит, чтобы понять, зачем нужна модель,
> давайте скажем, что нам нужно иметь параметр, по которому мы часто
> делаем запросы. например, мы выводит только людей с флагом active.
> добавим это поле в бд:
> rails g migration add_is_active_to_people is_active:boolean && rake
> db:migrate
> теперь в контроллере, где мы, к примеру, выводим список последних
> обновленных пользователей (обязательно с флагом is_active):
> def index
>   @people = Person.where(:is_active => true).order('people.updated_at
> desc').limit(5)
> end
> и так в каждом контроллере, добавляем where(:is_active => true),
> потому что нам везде нужны только активные персонажи. далее
> выясняется, что нужно еще какое-то поле, которое нам нужно для
> вычесления "активности" например is_banned должно быть false, и нам по
> всем контроллерам идти теперь, и добавлять  where(:is_active =>
> true, :is_banned => false)
> на сомом деле я пользуюсь правилом: если ты используешь какое-либо
> условие более 1 раза, сделай из него скоуп
> то есть идем в модель person.rb, и пишем там
> scope :active where(:is_active => true, :is_banned => false)
> и теперь в том примере вверху заменяем where(...) на active
> @people = Person.active.order('people.updated_at desc').limit(5)
> скоупы могут быть на что угодно (сортировка, лимит), могут включать в
> себя другие скоупы, вызываться по умолчанию (default_scope) и т.д. то
> есть профит очевиден - мы вынесли логику из контроллера в модель, что
> хорошо, потому что контроллеров много, действий в контроллерах много,
> а модель - она одна. в модели происходят различные валидации, так что
> вы смело можете писать Person.create(params[:person]) не заботясь о
> том, какие поля заполнены, какие нет - об этом вы заботитесь в модели.
> модель предоставляет обработчики типа before_create. отношения между
> моделями так-же настраиваются внутри модели.
> нужно только в табличку ключ добавить не забыть:
> rails g model book name:string written_on:date user_id:integer && rake
> db:migrate
> в модели персонажа
> has_many :books
> и в контроллере
> Person.active.where(:name => 'Lev').books
> получаем массив из книг.
> постепенно ваша модель разрастется и обогатится логикой, а контроллеры
> сведутся к 7 общепринятым действиям (index, show, new, create, edit,
> update, destroy), которые будут дублироваться от модели к модели, и вы
> откроете для себя inherited_resources, так что контролерры в
> большинстве своем станут пустыми. rails 3.1 позволяет из коробки
> наследовать и вьюшки, так что и их не будет, в приложении останутся
> только модели.
> надеюсь мой ответ воодушевит на более глубокое изучкение именно
> стандартов рельсов (MVC, RESTful)
> а таблицы... ну я о них думаю только когда они начинают (или будут)
> тормозить :) добавляю индексы. то есть там вопрос производительности
> On 3 июл, 16:49, Курган - Игорь Копырин <kopy...@mail.ru> wrote:
>
>
>
>
>
>
>
> > Вы считаете я вам ссылки просто так привел? Не посмотрел что там , и
> > не применил...
> > Вопрос из обсуждения  модель-представления-контроллер VS таблицы - SQL
> > запрос
> > переходит в обсуждение сколько много нужно знать что бы тут писать.
>
> > Вы не заметили что я уже все понял и поблагодарил, а вы еще меня
> > учите?
>
> > On 3 июл, 15:33, Maxim Filatov <pipopo...@gmail.com> wrote:
>
> > > On Jul 3, 2011, at 12:17 PM, Курган - Игорь Копырин wrote:
>
> > > > Есть ещеhttp://www.rusrails.ru/иhttp://russian.railstutorial.org/chapters/beginning#book_menu.
> > > > Не ужели так трудно промолчать если нечего сказать?
>
> > > Неужели (пишется слитно, кстати) так трудно прочитать хоть что-нибудь по теме, прежде чем писать в группу?
>
> > > --
> > > Best regards,
> > > Maxim Filatov

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

Комментариев нет:

Отправить комментарий