Carlos Brando

Nome do Jogo

Rails Way: Modelos gordos e controladores magros

Existe um jargão na comunidade Ruby on Rails conhecido como o “Rails way”, ou em bom português o jeitão de fazer as coisas no Rails. Não existe uma regra escrita sobre como desenvolver código em Ruby usando o Rails, mas a comunidade tem apoiado algumas praticas que tem se mostrado úteis e inteligentes.

Um grande problema que tenho encontrado com alguns alunos e até mesmo com profissionais “experientes” é que muitos que hoje programam em Ruby vieram de linguagens como Java, C# e PHP, e trazem para o Ruby on Rails os mesmos vícios que possuíam ao desenvolver nestas plataformas.

Para facilitar a vida destes programadores vou tentar mostrar algumas das “boas práticas” que um bom desenvolvedor Rails costuma adotar. E a primeira delas é “modelos gordos e controladores magros”.

A idéia é que toda a lógica para a manipulação de um recurso fique concentrada dentro da sua classe especifica. Esta idéia parece um pouco confusa e difícil de ser adota no inicio, mas para simplificar um pouco tente fazer o seguinte: Cada action de seus controllers deve chamar apenas um método de um modelo além de um find ou new iniciais, mesmo que seja necessário criar métodos .new ou .update personalizados.

Por exemplo:

def update
  @account = Account.find(params[:id])

  respond_to do |format|
    if @account.update_attributes(params[:account])
      format.html { redirect_to client_accounts_url(@client) }
    else
      format.html { render :action => "edit" }
    end
  end
end

Veja que no código acima estou inicialmente chamando o método find da classe Account e logo em seguida o método update_attributes. Este é o mundo ideal, apenas um método além do find inicial, no caso o método update_attributes. Estou sendo repetitivo para fixar a ideia.

Existem casos um pouco mais complexos que exigirão a criação de métodos personalizados e não há mal algum de cria-los. Imagine que no exemplo acima eu somente pudesse alterar os dados da conta (Account) do usuário atual. Neste caso eu poderia cria um novo método dentro da classe Account chamado update_attributes_by_user que além de receber o hash com os dados do formulário, também deve receber o usuário registrado na sessão atual:

def update
  @account = Account.find(params[:id])

  respond_to do |format|
    if @account.update_attributes_by_user(params[:account], current_user)
      format.html { redirect_to client_accounts_url(@client) }
    else
      format.html { render :action => "edit" }
    end
  end
end

Não importa o código deste método, o que importa é que a lógica por traz dele está no lugar certo, dentro do modelo. Enfim, esta é a ideia.

Em breve escreverei sobre outras boas praticas ao desenvolver softwares com Ruby on Rails.

Comments