Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009

Pragmatic Patterns of Ruby on Rails Yasuko OHBA( )

what I do • developer of Rails applications • • Everyleaf Corporation

sponsor booth • ﬁrst time to be a sponsor • we serve candies • you can play ‘Romantic Ruby’ !

my products • home accounting web service http://www.kozuchi.net • http://github.com/everyleaf/kozuchi/ tree

I started programming when I was 14 years old

only activities inside the company

the way to live happily writing codes

coding patterns with Ruby on Rails

the target • large & complicated applications • team

problems of large applications • different coding styles • nasty parts made

what is the ‘nice code’? • good design • easy to understand • easy to ﬁnd something wrong

coding patterns work ﬁne • make and share coding patterns • add some DSL (not too much)

what I won’t say • how to get the best performance • ActiveRecord’s alternatives

still able to maintenance when it gets complicated

many AR features in this presentation

ﬁnd starts from an AR object

ﬁnd a note by id /note/3 def show @note = Note.ﬁnd(params[:id]) end

ﬁnd a note of the current user /note/3 @note = Note.ﬁnd_by_id_and_user_id( params[:id], current_user.id) raise ActiveRecord::RecordNotFound unless @note

/note/3 @note = Note.written_by( curret_user.id).ﬁnd(params[:id])

hard to notice the luck of condition! @note = Note.find(params[:id]) @note = Note.find_by_id_and_user_id( params[:id], current_user.id) @note = Note.written_by( current_user).find(params[:id])

starts from an object def show @note = current_user.notes.ﬁnd( params[:id]) end

use the association def show @note = current_user.notes.ﬁnd( params[:id]) end

association class User < ActiveRecord::Base has_many :notes end

easy to notice problems @note = current_user.notes.ﬁnd( params[:id]) @note = Note.ﬁnd(params[:id])

who can access @note = current_user.notes.ﬁnd( params[:id])

ﬁlters to ﬁnd the starting AR object

most actions will use the AR object

example; CRUD of the speciﬁed group’s notes

• URL • /groups/15/notes • /groups/15/notes/3

• Note has group_id class Note < ActiveRecord::Base belongs_to :group end class Group < ActiveRecord::Base has_many :notes end

def index @group = Group.find(params[:group_id]) @notes = @group.notes.paginate(:page => params[:page]) end def show @group = Group.find(params[:group_id]) @note = @group.notes.find(params[:id]) end

the duplicated line @group = Group.ﬁnd(params[:group_id])

what’s the ﬁlter? • the separated logic which would be called around action • declarative

find the group in a filter class GroupNotesController < ApplicationController before_filter :find_group .......actions ...... private def find_group @group = Group.find(params[:group_id]) end end

DRY before_filter :find_group def index @notes = @group.notes.paginate(:page => params[:page]) end def show @note = @group.notes.find(params[:id]) end

example; change to allow access to members only def ﬁnd_group @group = current_user.groups.ﬁnd( params[:group_id] end

safe if it starts from @group def index @notes = @group.notes.paginate(:page => params[:page]) end def show @note = @group.notes.ﬁnd(params[:id]) end

ﬁlter urges developers to use @group

you can understand the controller’s summary from name and ﬁlters

understand the summary quickly class GroupNotesController < ApplicationController before_ﬁlter :ﬁnd_group

the points • a good controller name • readable ﬁlters

want to write business logics in models

merits of writing business logics in models • easy to test • easy to reuse • readable, easy to ﬁnd the target codes

a bad example class MyModel < ActiveRecord::Base def do_create(params) .... def do_destroy(params) ... end

why is it bad ? • it breaks MVC • hard to reuse

let’s move codes from controller to model in good way

move the logic branching on parameters from C to M

branching on parameters def update @note.attributes = params[:note] @tags = params[:auto_tagging] == '1' ? generate_tags(@note) : [] # do saving and tagging ... end

add an attribute for branching to the model

the condition params[:auto_tagging] == '1'

as an attribute of the model class Note < ActiveRecord::Base attr_accessor :auto_tagging end

change parameters structure { :note => {.....}, :auto_tagging => '1' } { :note => { ....., :auto_tagging => '1' }}

change the view for it <%= check_box_tag :auto_tagging %> <% form_for :note, ... do |f |%> <%= f.check_box :auto_tagging %> <% end %>

now it’s in params[:note] def update @note.attributes = params[:note] if params[:auto_tagging] == '1' generate_tags(@note) end .....

can branch in the model class Note < ActiveRecord::Base .... if auto_tagging ... end end

move the logic processing other models from C to M

the logic processing other models def update generate_tags(@note) end private def generate_tags(note) tags = Tag.extract(note.body) note.tag_list = tags.join(',') end

also often written in controller

put it into model’s callback class Note < ActiveRecord::Base before_save :generate_taggings private def generate_taggings return unless auto_tagging tags = Tag.extract(body) self.tag_list = tags.join(',') end end

what’s the model’s callback? • methods called before/after save or destroy

Rails Model You normal method call save (validation) before_save do saving after_save

now we’ve done it ! • easy to test • easy to reuse • readable, easy to ﬁnd the target codes

other patterns • multi levels for validation • design & coding policy for STI • use owner object’s attributes in association • how to make routes.rb a little readable

try to choose the most natural style for RoR

what is the most natural way in Ruby on Rails?

express business logics as models

always think who should do that job

Note or User ? @note = Note.ﬁnd_by_id_and_user_id( params[:id], current_user.id) @note = current_user.notes.ﬁnd( params[:id])

you can’t always decide it from tables

2. follow the principles of RoR

principles of RoR • DRY • CoC • RESTful

accept RESTful in Ruby on Rails

one controller for a type of resources

you can ﬁnd it in URL /companies/everyleaf/notes/3

one controller should provide one resource type’s CRUD

might have been derailed class BlogsController < ApplicationController def create_comment end def comments end def destroy_comment ...

write codes in model’s standard ﬂows

standard flows • find • new → save (create) • find → save (update) • find → destroy

new attribute = before_ build validation before_ after_ validation save validation creation after_save

write codes in appropriate place

where, what new attribute = before_ build validation before_ after_ validation save validation creation after_save

don’t go too far from the basic styles

it’s normal to Rails programmers

in developing large & complicated application

it’s important to keep codes nice

be aware of coding patterns, and share them

coding patterns ﬁtting Ruby on Rails

make source codes easy to read for general developers

Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009

More Related Content

What's hot

Viewers also liked

Similar to Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009

More from Yasuko Ohba

Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009