Shout it kick it on DotNetKicks.com
imageA demo that I added to my MVVM talk is one that compares a “Ball of Mud” application with a componentized ) application with the exact same set of features. I do this to contrast a messy, un-testable work of code to a cleanly separated, testable work. The application I chose to write is a Twitter search application in WPF. When you download the code, you will see two folders: “BallOfMud” and “MVVM”.
The “Ball of Mud” app includes the entire app in a XAML file and a code-behind. The code is incredibly dense… it does a TON of stuff, all in one page of code. Unfortunately, is practically un-testable. Even if you could test it, the code hits a live twitter.com. Not the way you want to write tests. This way of writing software works well for demos, but it certainly does not scale to real-life applications.
The MVVM example, on the other hand, is significantly broken up into components (4 layers). There are 2 Views (TwitterSearchView and TweetView) with 2 corresponding ViewModels. Then, there is a Model layer which is responsible for parsing data that comes from the Service layer into “Tweets”. There is more code than the “Ball of Mud” example, but the code is testable, and modular. You can swap out different services or models, if you wish. In fact, in the Model layer, you will find a “CannedData” class that I use when I don’t have an internet connection when I give my presentation. It just swaps in. This example might feel like “overkill”, but as the application grows in scope, this architecture will scale exceptionally well.