I’m helping a software development company to “convert” a VB6 application to .NET. We have a very tight schedule and originally planned to do a convert with some help from the Conversion Wizard and some parts manually, but still close to their current version. The goal was to just get over to .NET and from there develop the product that they and their customers wanted, but because of a big chance for them to get a new really big customer, the plans changed. The big customer wants a web based application since there are many users, so we decided to switch to a Silverlight client.
After doing some spikes and proof of concepts elaboration we have now settled on a design where we hope to be very productive.
We are using the following technology:
This seems very new all over the place, but we will also use Enterprise Library 4.1 to do classic data access so that we can reuse a lot of SQL code from the VB6 application.
First we had a design without WCF RIA Services and just using plain WCF Services, but after some elaboration we found that WCF RIA Services would help us a lot. Many videos and examples that uses WCF RIA Services also uses Entity Framework and then exposing the domain model to the client. We did not want to expose the domain model to the client, because the domain model will have other perspectives on its design than the user interface.
Early on we decided to use Model-View-ViewModel (MVVM) for the user interface (actually this was the plan even for the Windows Forms client) to get a good separation of concerns and increasing testability. This pattern really shines with WPF and Silverlight clients, since these platforms have powerful data bindings and also support for Commands (in Silverlight 4).
Every time I’ve used the MVVM pattern before I have always only exposed the View Model to the View, but this time we choosed to actually expose the Model to. I had some thought about this, but finally settled on seeing the Model as a Presentation Model, aka a model designed for the View. There are a lot of time to save and powerful tooling support to use that was part of the reason to this choice, because it fits really nice with WCF RIA Services and the data annotations in .NET 4.0. This is why I see the WCF RIA Services as a part of the client. The services themselves are also designed from the use cases and tightly coupled to the client (there are for example no SOA thinking in these services). The data transfer objects (DTOs) is designed to fit the View and are therefore a combination of DTOs and presentation model objects. This means that we tag the classes in the presentation model with data annotations. This classes are also generated by the WCF RIA Services tooling on the client with the same data annotations. When we bind the controls in the Silverlight views against these classes the controls picks up the validations and the display information (labels/captions) giving us productivity and not forcing us to repeat our self.
The Server part is reusable and will probably have other clients in the future as a ASP.NET and/or WPF user interface (or why not even a Windows Phone 7 UI?).
We started with creating clean POCO classes for the domain model and then using the Entity Framework code first CTP 3 to map it against our database, but we have now switched to use the Entity Framework designer and downloaded the POCO generator through Visual Studio Extension Manager. The reason was mainly because we had a problem with mapping our relations (which is solved now) and when switching we found some productivity enhancement with using the designer (at least so far :~). The domain classes are mapped with the wonderful AutoMapper to the presentation model classes.
When catching up on all this new technology I found great value in reading the extensive amount of blog posts that Fredrik Normén has written about Silverlight and WCF RIA Services so that is a great resource if you want to get started. He has also used DTOs/Presentation Model with WCF RIA Services and not exposing the domain model.