Lately, I have been doing some reading. It all started last week when I decided to watch a few MVC tutorial videos on asp.net. That wasn’t enough, so, after some searching, I ended up reading the first six chapters of Programming ASP.NET MVC 4 by Chadwick, Snyder & Panda on oreilly.com. A very interesting read, for sure, especially because the book has been written for an audience that is – like me – already familiar with ASP.NET Web Forms – see Chapter 2.
Then, in Chapter 5, the authors take an architectural detour, explaining in details the implementation of the MVC design pattern employed by Microsoft in the ASP.NET MVC Framework. Let me quote a few lines, taken from that chapter, that really helped me understand how things work:
The original MVC pattern was designed with the assumption that the view, controller, and model were all within the same context. The pattern relies heavily on each component being able to directly interact with each other and share state across user interactions. Controllers would use the observe pattern to monitor changes to the view and react to user input. This approach works great when the controller, view, and model all exist under the same memory context.
In a web application things are stateless, the view (HTML) runs on a client inside of a browser. A controller can’t use the observe pattern to monitor changes; instead a HTTP request needs to be sent from the view to a controller. To address this the Front Controller pattern has been adopted. The main concept behind this pattern is when a HTTP request is sent; a controller intercepts and processes it. The controller is responsible for determining how to process the request and the result sent back to the client.
Later in that chapter, when the authors begin talking about Design Principles, the mentioned SOLID, an acronym of acronyms that describes a particular set of application development principles that drive proper object-oriented design and development. This captured by attention and lead me on an interesting tangent. I ended up listening to a very interesting podcast on Hanselminutes (transcript here) in which Scott Hanselman interviews Robert C. Martin (aka Uncle Bob), author of The Principles of Object Oriented Design, an article in which he introduced SOLID:
The five principles of class design are:
Single Responsibility Principle: A class should have one, and only one, reason to change.
Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
Interface Segregation Principle: Make fine grained interfaces that are client specific.
Dependency Inversion Principle: Depend on abstractions, not on concretions.
The entire podcast is quite interesting and deserves to be listened a couple of times, for sure. But there was one part that I really found interesting, when Bob was talking about modeling languages. At some point Scott said:
Scott Hanselman: Yeah, and at some point, someone will do a switch statement and then they’ll spackle over it and pretend it didn’t happen and then it becomes legacy code.
Robert C. Martin: Wow, yeah, have you read Feathers’ book on legacy code? His definition of legacy code is code that’s not under test.
Scott Hanselman: Exactly.
Robert C. Martin: If you don’t have tests for it it’s already legacy code.
Then, yesterday night, I couldn’t fall asleep, so I ended up digging a bit more and listening to some related .NET Rocks podcasts:
- James Whittaker takes testing seriously
- Michael Feathers talks legacy code
- Bob Martin (Uncle Bob) on being a professional
At the moment I don’t have much else to add, since I haven’t really digested all this information, yet. Please take this blog post for what it is, which is, more or less, a way for me to bookmark all these interesting sources and to remind myself to come back to these soon for a deeper dive.