Model View Controller and Beautiful Code

Dr. Blip's PC-Doctor Blog

Model View Controller and Beautiful Code Wed, Nov 7. 2007

I've been reading Beautiful Code. It's a fun book with chapters written by a few well-known programmers about some beautiful code that they've written or seen. They all have wildly different views on what makes code beautiful, so it's pretty entertaining. It's fun seeing what programmers I've heard of think is beautiful. Brian Kernighan, for example, wrote about some string processing code. I found that extremely entertaining and ironic. Yukihiro Matsumoto had an impressively concise description of what it takes to make beautiful code. It was refreshingly in character with the Ruby philosophy.

Most of the authors were completely unknown to me. However, even though the most obscure is more famous than me, I'm still going to tell you about some beautiful code that I run into frequently.

The Model View Controller (MVC) design pattern is, perhaps, one of the oldest out there. It's been used for almost 30 years now, and it is still an extremely clean way to divide up the responsibilities of a user interface. When I see it implemented well, it's extremely satisfying.

For those of you who grew up using Microsoft's GUI frameworks, you may have never seen this done well. .NET Forms and MFC make it difficult to implement it correctly. (In fact, this topic was inspired by me working simultaneously on a Rails and a MFC project.) Ruby on Rails, by the way, revolves around the MVC design pattern.

What's so beautiful about the pattern?

It cleanly separates three different activities. The separation is clean enough that the pattern is relatively easy to use. It's usually easy to figure out whether some functionality should go in the model, the view, or the controller.

Furthermore, even in a highly interactive GUI, the program becomes easily testable. The view is the only part that interacts directly with the user, and, other than interacting with the user, the models and controllers have all of the functionality. (This statement becomes less true if you're writing custom controls such as a text editor.) If you test the models and controllers, then you've tested a large fraction of the code.

I always smile when I see some MVC code that works well.
Posted by fred.bertsch in Software Comments: (6)
Twitter Bookmark Model View Controller and Beautiful Code at del.icio.us Facebook Google Bookmarks FriendFeed Digg Model View Controller and Beautiful Code Bloglines Model View Controller and Beautiful Code Technorati Model View Controller and Beautiful Code Fark this: Model View Controller and Beautiful Code Bookmark Model View Controller and Beautiful Code at YahooMyWeb Bookmark Model View Controller and Beautiful Code at Furl.net Bookmark Model View Controller and Beautiful Code at reddit.com Bookmark Model View Controller and Beautiful Code at blinklist.com Bookmark Model View Controller and Beautiful Code at NewsVine Bookmark Model View Controller and Beautiful Code at blogmarks Bookmark Model View Controller and Beautiful Code at Ma.gnolia.com Stumble It! Print this article! E-mail this story to a friend! Identi.ca

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

#1 - Jonathan Aquino said:
2007-11-09 19:11 -

I love the MVC directory structure of Ruby on Rails projects. Very clean - everything has its proper place.

#2 - WildKid said:
2007-11-27 03:11 -

Really good and really interesting post. I expect (and other readers maybe :-)) new useful posts from you!
Good luck and successes in blogging!

#3 - fred.bertsch 2007-11-27 07:35 -

Thanks for the praise. :-) I should have a new one up in a few days.

#4 - Phil McT 2007-11-27 10:39 -

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.

#5 - fred.bertsch 2007-11-27 12:24 -

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.

#6 - Phil McT 2007-11-28 06:02 -

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).


The author does not allow comments to this entry