design patterns

rubyonrails-talk
1

Hi everyone I’m Maximiliano Guzenski from Brazil and I am programing on ruby on rails only a couple of months. I read a lot of books and articles about it but I could not clarify some doubts about design patterns:

  1. Is it really good put some sql command on controller? because all articles that I see use sql into controllers, like:

    my controller

    @categories = Category.find :all, :conditions => ["date <= ? ", Date.today] :order => “name”

    Or Should I create methods on model? #my controller @categories = Category.find_all_before_date

    @#my model (date = Date.today) find :all, :conditions => ["date <= ? ", date] :order => “name”

  2. In my app I have some reports, like that: #report controller sql = <<EOF select categories.id, categories.name , sum(ledgers.value), sum(budgets.value) from categories, ledgers, budgets where categories.id = ledgers.category_id and categories.id = budgets.category_id group by categories.id, categories.name EOF

    So, Where should I put this sql? model or controller ?

    and How sould I execute it? using Category model?

    Category.find_by_sql(sql)

    or Is there way to use a generic model ?, some like that ActiveRecord::Base.find(sql)

cheers,

2

  1. It’s all about agile development. If you find yourself using exactly that string, or very close to it, then look into moving it from the controller into the model. Make sure you have tests in place to verify that you didn’t break anything through this refactoring.

  2. For specific hard-coded SQL, probably best to put it in the model. Also, Model.find_by_sql is perfectly fine.

Hope that helps. Welcome to Rails!

Jason

3

Hi Maximiliano,

If you want to be strict about design patterns, then you want to keep database queries and related find_by methods in the Model layer of the MVC framework.

Also, that’s what the “Agile Development with Rails” book recommend. Just a little extra point, you might want to use a more descriptive name for the “sql” variable. It’s all about readability.

Cheers,

Mauricio

=== I’m brazilian, so here’s the same thing in Portuguese :wink: ====

Se você tá estudando design patterns e quer seguir os padrões, então mantenha todos os métodos e buscas relacionados ao banco de dados na camada de Modelo do padrão MVC.

O livro “Agile Development with Rails” também recomenda isso. Além disso, eu recomendaria que você usasse um nome diferente pra sua variável de busca, algo mais descritivo do que “sql”, pra facilitar a releitura desse código.

Abração,

Mauricio

4

If your web application data is tied yo your web application, then you could probably just have all your SQL in your model. If you want to use the same data from outside of the web application, then your model should be totally outside of Rails and just have a thin model to your ‘real’ model. The controller, in general, shouldn’t really know anything about the underlying model. It just, in general, controls flow. Also, MVC isn’t really a pattern, it;s a compound pattern. It’s made up of other patterns. So, if you’re model is outside of Rails, you could use an adapter from your thin model to your real model. I hope this helps but as with everything, there’s more than one way to do it, and everyone will have their angle on how MVC works. What’s good for me, might not be good for you. -Ants

5

just a comment on #1, +1 to everybody's suggestion of keeping it in the model. check out "Skinny Controller, Fat Model": http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model