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.
a thousand lines of code 
While you are reading into SOLID and mvc think about how you would use the principles to separate out sitecore interactions form your code into a separate layer of code so you can test the rest of it out in isolation.
Good point. Sitecore in itself, the way it comes out of the box is one giant solution, and makes this particularly challenging. What are your suggestions?
uptill 6.5 I didn’t have any idea how to go about this. But with 6.6 and mvc you could build out a data layer in your app which deals with all the sitecore bits. Creating a domain model with classes corresponding to each of your templates and have repository classes which encapuslate access to them through sitecore. This way any issues related to sitecore are contained in ur data layer and ur core logic cud be separated out. The other hard part is the sitecore context. It’s super hard to mock it out and use dummy values to write out unit tests to validate ur logic. For this reason it makes sense to keep sitecore interactions encapsulated in the data layer.
Very interesting… would you be interested in writing a featured post with an example on how to implement this?
Sorry, i never log into WordPress and totally missed your reply :). Would have loved to write a guest post but I think the topic isn’t relevant any more with standardized solutions available for the hand made solution I had listed above