Information
Resources
Categories
Model View Controller and Beautiful Code
Posted by fred.bertsch in Software at 11:46 | Wednesday, November 7. 2007
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I love the MVC directory structure of Ruby on Rails projects. Very clean - everything has its proper place.
Really good and really interesting post. I expect (and other readers maybe 
) new useful posts from you!
Good luck and successes in blogging!
) new useful posts from you! Good luck and successes in blogging!
I found this page while searching for some info on a question I have regarding where certain code should live in the MVC framework.
It's probably best illustrated with an example. Say I have a message board that displays a picture and other info about the user who posted.
The main logic of the message board is to select an original post and all the replies. But the information I want about the user is stored in a different table/model.
Let's put it in the controller - after all, I want a nice simple view with no business logic. But then the controller has to know everything the view might need. And all this data collection might not be required for a different view of the topic (e.g. a mobile phone version, an XML extract)
Let's put it in the view - after all, it's really a presentation requirement, and I can write a helper function to keep the logic neat. Testing is a problem though. And the view can quickly become a mess of logic.
Let's put it in the model - erm..okay, let's not. Right?
If anyone can give any insight or point me to a resource, I'd be obliged.
It's probably best illustrated with an example. Say I have a message board that displays a picture and other info about the user who posted.
The main logic of the message board is to select an original post and all the replies. But the information I want about the user is stored in a different table/model.
Let's put it in the controller - after all, I want a nice simple view with no business logic. But then the controller has to know everything the view might need. And all this data collection might not be required for a different view of the topic (e.g. a mobile phone version, an XML extract)
Let's put it in the view - after all, it's really a presentation requirement, and I can write a helper function to keep the logic neat. Testing is a problem though. And the view can quickly become a mess of logic.
Let's put it in the model - erm..okay, let's not. Right?
If anyone can give any insight or point me to a resource, I'd be obliged.
This is the big problem with MVC code. Where the heck does some functionality go? It sounds as though your problem needs to be divided some more. I�d put a bit of the responsibility in all three places.
The view has to display user info and message info. That�s okay. It can display whatever the controller gives it access to. The trick is that it shouldn't actually find that information. It should be given the information in a nice little package.
Some processing needs to be done, however. For each message we want to display, we need to find the associated user.
We don't need to find the associated user name and user photo, however. The view can extract information from a model without claiming that it's doing any processing. After all, the model is the one handing out the information. The view only asks the user model for a photo.
What does the controller want to do? The controller wants a particular display of a list of messages. It doesn't want to know that the view is actually going to display the photo of the user who wrote the messages. That's not important to the controller.
Who finds the user attached to a message, then? I would put that part in the message model. The message model should know who wrote it. In the table, it might be a foreign key, but the model can release more than that. It can return the entire user model object that is responsible for that message object.
In summary, the controller wants a list of messages displayed. It sends that collection to a view. The view queries each message for its content, its owner's name, and its owner's photo. It displays all of that. It's testable because all the view is doing is asking the model for the info. That can be tested easily.
In general, I like to put things in the model. I feel pretty happy about my code if I can find some extra functionality that I can cleanly pull out of the model and into the controller.
The view has to display user info and message info. That�s okay. It can display whatever the controller gives it access to. The trick is that it shouldn't actually find that information. It should be given the information in a nice little package.
Some processing needs to be done, however. For each message we want to display, we need to find the associated user.
We don't need to find the associated user name and user photo, however. The view can extract information from a model without claiming that it's doing any processing. After all, the model is the one handing out the information. The view only asks the user model for a photo.
What does the controller want to do? The controller wants a particular display of a list of messages. It doesn't want to know that the view is actually going to display the photo of the user who wrote the messages. That's not important to the controller.
Who finds the user attached to a message, then? I would put that part in the message model. The message model should know who wrote it. In the table, it might be a foreign key, but the model can release more than that. It can return the entire user model object that is responsible for that message object.
In summary, the controller wants a list of messages displayed. It sends that collection to a view. The view queries each message for its content, its owner's name, and its owner's photo. It displays all of that. It's testable because all the view is doing is asking the model for the info. That can be tested easily.
In general, I like to put things in the model. I feel pretty happy about my code if I can find some extra functionality that I can cleanly pull out of the model and into the controller.
Thanks for the follow-up, Fred.
I think one of the trade-offs is "loading data up-front in all cases" versus "loading data as late as possible". The former is more efficient but might be completely unnecessary if the view isn't going to use it.
The code could be in the model in both cases.
I suppose you'd just have to look at the usage patters, and whether you can write 'on demand' code that was almost as efficient as the up-front work. (By efficient, I mean a single select/join on a table, versus hitting the table every time you want to display a topic).
I think one of the trade-offs is "loading data up-front in all cases" versus "loading data as late as possible". The former is more efficient but might be completely unnecessary if the view isn't going to use it.
The code could be in the model in both cases.
I suppose you'd just have to look at the usage patters, and whether you can write 'on demand' code that was almost as efficient as the up-front work. (By efficient, I mean a single select/join on a table, versus hitting the table every time you want to display a topic).
© 2009 PC-Doctor, Inc. ALL RIGHTS RESERVED.
Quicksearch
Polls
Did you buy an iPhone 3G?
Archives
Archives