I've finally finished reading Pro ASP.Net MVC Framework by Steven Sanderson. The book is slightly dated, since it discusses the technology used in Visual Studio 2008 and without any mention of the new Razor engine, but these are details that are not important to the content of the book anyway. I can say that it is a very nice book and it was worth reading, especially the first part.

There are two parts to this, the first being a TDD ASP.Net MVC web shop application built step by step and explained line by line. It goes through some Domain Driven Design concepts as well, it does unit testing and mocking, even shows off a little dependency injection via Castle Windsor. What I liked most, though, is how painstakingly thorough Sanderson was explaining every single detail. He didn't assume anything as he documented every step of the way, down to what lambda expressions are and what .Net features he was using.

The second part of the book is a little less readable, as it goes through the classes and features of ASP.Net MVC, complete with methods, properties and small samples. I highly recommend reading this part while actually experimenting with the framework on the computer. Even if you do not, this part of the book remains a very valuable reference for when you do. In this section of the book you can learn about data entry, Ajax and partial updates, application security and deployment, even how to mix classic ASP.Net with MVC, though not really recommended.

The bottom line is that Pro ASP.Net MVC Framework is a must read for a developer learning ASP.Net MVC. There is an updated version of the book for VS2010 and .Net 4 that I think that I will also read (the book was so good). Here is the link for Pro ASP.NET MVC 2 Framework.

and has 1 comment

Foundations of Programming is a free ebook written by Karl Seguin, a member of the CodeBettter community. As you might have guessed by now from the fact the book is free, he is Canadian. :)

There is even a Foundation of Programming site, where there are a lot of free resources on programming as well as other free ebooks.

About the book, it is a good read. A bit inconsistent, it seemed, since it starts with chapters on Domain Driven Design, Persistence, Dependency Injection, Unit Testing, then moves to Object Relational Mappers and then has three "Back to Basics" chapters about Memory, Exceptions and Proxies. There is a logic to this, but the jump from expert to junior programming and then back again was a little annoying.

Interestingly enough, Karl Seguin is a former Microsoft MVP that advocates ALT.Net.

Bottom line, it is a good and easy read for all levels of programming. People might be attracted to the way Karl is expressing his opinion without actually being biased towards any of the usual debate parties. Beginners might learn about the foundations of the stuff they take for granted, like heap/stack, while more advanced developers can start thinking about structured ways of doing work, like DDD and automated unit testing. Neither chapter is a complete new revelation, but taken together, they do present a clear picture of programming from Karl Seguin's perspective and can surprise you on matters you thought you had complete control over.

Tomorrow I start work on a WPF application that is supposed to be as modular as possible. Since I know almost nothing about WPF or modular applications, I started researching a little bit how it should be done. Basically I found only two ways I cared to expand my research on: Prism (patterns & practices Composite Application Guidance for WPF and Silverlight) and MEF (Managed Extensibility Framework).

Unfortunately I've only had time to do some Prism, although MEF seems to be the way to go. First of all it is a general framework, not limited to WPF/Silverlight and secondly it is used in the new Visual Studio 2010 release. What is amazing is that both frameworks come as freely available opensource.

Ok, back on Prism. The concepts are simple enough, although it takes a while to "get" the way to work with them. Basically you start with:
  • a Bootstrapper class - it initializes the Shell and the Catalog
  • a Shell - a visual frame where all the modules will be shown
  • a Module Catalog - a class that determines which modules will be loaded
  • an Inversion of Control Container - class that will determine, through Reflection usually, how to initialize the classes and what parameters they receive
  • a RegionManager - class that will connect views with Regions, empty placeholders where views are supposed to be shown
  • an EventAggregator - a class that is used to publish events or subscribe to events without referencing the objects that need to do that


Easy right? I don't even need to say more. But just in case you don't have a four digit IQ, better watch this four part video walkthrough:
Creating a modular application using Prism V2 - part 1
Creating a modular application using Prism V2 - part 2
Creating a modular application using Prism V2 - part 3
Creating a modular application using Prism V2 - part 4.

I did try to take the WPF Hands on Labs project and mold it with Prism and it partially worked. The problem I had was with the navigation controls. These work as a web application, where you call the XAML and it has to be a file somewhere, and you have events for the calling and returning from those "pages". I could find no way to encapsulate them so I could build no modules out of them and the whole thing collapsed.

So, for a quick walkthrough on using Prism with WPF.
Creating the core:
  1. create a new WPF application project
  2. reference the Prism libraries
  3. create the Bootstrapper class by inheriting UnityBottstrapper that will determine the Shell (a WPF window class) and set it as the application MainWindow, as well as create the type of ModuleCatalog (either take a default one or inherit one from IModuleCatalog) you want
  4. create the layout of the Shell and add region names to the controls you want to host the loaded modules (example <ContentControl Grid.Row="0" Margin="2" Regions:RegionManager.RegionName="SearchRegion"/>
.

Creating a module:
  1. create a new library project
  2. add a class that inherits IModule
  3. the constructor of the IModule can have different parameters, like an IRegionManager, an IUnityContainer, an IEventAggregator and any other types that have been registered in the container (I know it hasn't been initialized in the core, the catalog takes care of that). The IoC container will make sure the parameters are instantiated and passed to the module
  4. register views with regions and any additional types with the IoC container in the Initialize method of the module
  5. create view classes - WPF controls that have nothing except the graphical layout. Any value displayed, any command bound, any color and any style are bound to the default DataContext. The views will receive a view model class as a constructor parameter which they will set as their DataContext
  6. create the view model classes - they also can have any types in the contructor as long as they are registered with the IoC container, stuff like the eventAggregator or a data service or other class that provides the data in the view model.
  7. provide all the information needed in the view as public properties in the view model so that they can be bound
  8. subscribe or publish events with the event aggregator


As you can see, most of the work is done by the modules, as it should be. They are both communicating and displaying data using the event aggregator and the binding mechanisms of WPF. There are some differences between how WPF and Silverlight approach some issues. The Prism library brings some classes to complement the subset of functionality in Silverlight that are not needed in WPF. However, one can still use those for WPF applications, making a transition from WPF to Silverlight or a mixed project more easily maintained.

The video walkthrough (as well as my own text summary) are based on the rather new Model-View-ViewModel pattern, which many people call a flavour of MVC. It was created specifically for WPF/Silverlight in order to separate behaviour from user interface.

Expect more on this as soon as I unravel it myself.