Some minutes hours ago, in a phone conversation with a dear friend, who also happens to be a decent programmer, I expressed my feeling about the Model View Controller pattern Rails is claiming to adhere to. Something feels wrong. And not only MVC in Rails.
Say I have a bunch of recipes, all nicely assigned to a smaller subset of categories. (Does that sound familiar?)
In Rails, if I would want to show all recipes on the recipe index page.
My controller class would look like this:
class RecipeController < ApplicationController
model(:recipe)
def index()
@recipes = Recipe.find_all()
end
end
With an accompanying model:
class Recipe < ActiveRecord::Base
belongs_to(:category)
end
What disturbs me is the find_all() method in Recipe.
Yes, I understand that Recipe subclasses ActiveRecord. But I would not expect the Recipe class to know about all its kin:
Richard.find_all()
paraphrased
"Say Richard, pass me a reference to all people on earth, will you?"
Would it make sense to have some other class that would know about Products and supply the controller with data?
Another thing that bothers me is the php’ish way of having Ruby code in templates.
<% @recipes.each do |recipe| %>
<%= recipe.name %>
<% end %>
Aren’t that model instances we’re massaging in our view? Doesn’t that make our view partly a controller too?
Looking for answers I found an in-depth article (MVC and web apps: oil and water) by Harry Fuecks on MVC and its applicability in web applications. Take your time to read the articles he links to too.
Please let me know what you think.
Pay attention. I’m not bashing Rails. Beautiful apps have been written in that framework. I’m a paying Basecamp user, for example.
And the truth is out there.
Nederhoed 
January 11, 2006 at 04:49 |
Finder methods: I think you’re confusing the purpose of a class with the purpose of an object. These are different things. The class represent the kind of something where the object represents an instance of that kind.
So you would never have a class called Richard asking for all the people in the world. You would have a class called Person and an object of that class with a name attribute that could be “Richard”. Thus, you’d call Person.find(:all). Which is of course exactly the “find all the instances of the person classs” or “find all the people”.
It may be easier to think of if you consider the relationship between table and row. It’s much the same concept. The table represents the class, the rows the objects.
Views in MVC has always know of models. That’s their job, basically. To provide a view for the models. The controller’s job is to, well, control the flow of the application. What happens when the user clicks this button? Or when someone enters a password on the login screen?
You might find it useful to read up on these subjects in books like Patterns of Enterprise Applications Architecture by Martin Fowler. It explains patterns like Active Record and Model View Control. Regarding the relationship between classes and objects, I’d recommend getting a good primer on object-orientation.
Best of luck with your learning process!
January 11, 2006 at 10:40 |
Merci beaucoup for your feedback. Your class-object paragraph made it clearer. I oversaw that distinction in my blog entry.
Still, you can still query an instance for other instances, right?