Wednesday, July 29, 2009

Defining a reference architecture for Silverlight LOBs

Update October 2010: I’ve started a new in-depth series on my current Silverlight 4 Reference Architecture.

Recently I've been catching up on Silverlight by reading Pro Silverlight 2 in C# and the many blogs and articles on Silverlight 3 and I'm seriously impressed. The reason for this sudden interest is the fact that I'm considering Silverlight as an alternative to ASP.NET for building line-of-business applications. Silverlight 2 was promising, but lacked some important features that are required in full-screen Silverlight apps. However, Silverlight 3 has introduced some major improvements that convinced me that it is finally ready for replacing ASP.NET for controlled environments.

Since I'm quite fond of Martin Fowler's approach to Evolutionairy Design, I'd like to have at least a rough idea of where I'm going to in terms of architecture and technology support. Consequently, I've been thinking hard to come up with a list of features and ideas I'd like to consider in a SL architecture. The list is not complete, so I’ll adapt it regularly. But since I assume more people are trying to cross that same bridge, I though sharing my wish list could be useful.

General

  • Simple Design, Test-Driven Development and Refactoring are the foundation of all design and development efforts.
  • I will explicitly consider every recommendation from the RIA Pocket Guide and make sure they are either included in the design or made part of the product backlog.
  • I'm seriously considering to use MOQ instead of Rhino Mocks. I've been using Rhino for over two years, but Ayende hasn't reported much development anymore and its Silverlight support is only alpha. MOQ has official Silverlight support and appears to be very active.
  • I'll start with Visual Studio 2008 SP1, but will switch to Visual Studio 2010 Beta 2 when it arrives and has support for RIA Services.

The Application Server

  • RIA Services to expose DTOs to the client. I have thought long and hard about how to fit RIA Services in a system, but I refuse to directly expose the domain model and pollute it with explicit choices about how far RIA should serialize a my domain entities. Therefore, I will expose DTOs only, even though I loose the automatic propagation of validation logic to the client.
  • A Domain Model roughly designed according to DDD principles where cross-aggregate logic will be covered by Domain Services.
  • Obviously I'll use NHibernate accompanied by LINQ and Fluent NHibernate (download them from here if you want a set of compatible builds).
  • I'll still use the Repository pattern to hide any LINQ-to-NHibernate limitations. They will be exposed through an NHibernateObjectContext that serves as the unit-of-work and essentially wraps the ISession
  • I'm considering to introduce Domain Events to keep any infrastructural logic from poluting the domain model. However, I'm not sure how worthwhile this purist approach will be.
  • I've spend too much time hand-coding this translators in earlier projects, so I'm open to try out AutoMapper for this.
  • As usual, I'll use Enterprise Library 4.1 on the backend for Policy Injection, Exception Handling, Validation and Logging. I'm not sure when version 5.0 will arrive, but I like its feature set. If it arrives in time, I will consider migrating (the 3.0 -> 4.1 migration was trivial).

The Silverlight client

  • The use of Regions and Views such as the Composite Application Guidance (CAG) is providing, but without the concept of modules. The Web Client Software Factory had a similar concept, but I never found real use for them anyway.
  • An Event Aggregator to allow communication between views and other components without them needing a direct reference to eachother. I'm not yet sure which one I'll use. CAG has a nice one, but Jeremy's version might be interesting as well.
  • Dependency Injection through Unity for Silverlight.
  • I wish there was a Policy Injection framework for Silverlight as well...
  • RIA Services also adds a very nice mechanism for sharing code between the server and the Silverlight client, but I'm not sure yet how I'll use it. I think this is something that will become clear during development.
  • The RIA DomainContext will be accessed through an interface so that the ViewModel classes can be unit tested properly without any dependency on RIA.
  • INotifyPropertyChanged using lambda expressions instead of literal property names
  • Model-View-ViewModel (essentially Presentation Model with INotifyPropertyChanged and INotifyCollectionChanged support)
  • Some mechanism for hooking Silverlight controls to ICommand objects. I'm not sure yet whether I like the CAG implementation, so I may have to find an alternative.
  • Silverlight Toolkit and Telerik's RadControls for Silverlight
  • Deep linking with SL3's Navigation Framework

Sunday, July 19, 2009

NHibernate 2.1.0 GA with LINQ and Fluent

NHibernate 2.1.0 GA has just been released on SourceForge, so I thought it useful to compile the latest versions of both Fluent NHibernate (revision 530) and the NHibernate.LINQ (revision 915) against this new build. You can download them in one package from here.

Saturday, July 18, 2009

Book Review: Code Complete 2nd Edition

A few months ago, me and colleague Jonne Kats had a discussion on whether or not to refactor a single- line non-intuitive expression in a properly named method. Just for the sake of the argument, I was against this particular instance, and he was in favor of many very small methods. I felt it was more a matter of personal preference, but he challenged me by referring to the book Code Complete , written by Steven McConnell. Obviously, I took on this challenge and read the 2nd edition.

    clip_image001

The 2nd edition of Code Complete holds about 900 pages, but is definitely worth the read. The first 200-250 pages deal with general considerations for building high-quality software, followed by an equal amount of pages dealing with the typical interpretation problems that have made coding standards so popular. To me, those chapters provided additional food for my enthusiasm towards coding guidelines. Especially the stuff dealing about naming classes and members helped me gain additional arguments for making developers understand their significance. The remainder of the book covers almost every noticeable aspect of software development. Some chapters are very technical and deal with topics such as debugging practices, performance tuning, productivity tools, but others are actually very high-level and cover system integration and configuration management, project management, and management involvement in general,

The book uses examples written in VB, C++, Java and occasionally in C#. That was quite nice because even though I'm a former C++ developer, I forgot about the peculiarities of C++ and how much cleaner C# really is. Consequently, some of the examples were not really applicable to me. And since I've already spend a good deal of my career on coding, layout and design guidelines, I skipped most of the chapter covering code layout. The chapters on debugging and programming tools were a bit obsolete as well, because debuggers and development environments have matured incredibly since 2004, the release date of this book.

On the other hand, in spite of its age, the book is incredibly actual. Many of the practices explained in this book are now considered Agile practices. And were it really stands off against all the other design-related books is its extensive use of hard facts. I can't remember reading a technical book that caused me to send a few pages to my direct supervisors or my customer's management team so often. It is full of comparisons and study reports explaining why practices such as automated testing, pair programming, coding standards, and proper naming work so well; Steven did not held himself back on psychological and empirical studies. And the beauty of this all is that it is very lighthearted easy read, similarly to Jimmy Nilsson’s DDD with C# book, and a welcome change to the excellent but very dry Domain Driven Design by Eric Evans.

So what about that discussion with Jonne? Well, as usual when we have a discussion on topics such as this our intentions and goals are the same, but somehow we always differ in nuance. In this particular case, I must agree that replacing the non-intuitive expression with a single-line method was the right advice. That doesn’t mean you have to do that everywhere, just stick to the rule that a method should do one thing, and do that thing right. Just read the book and learn to gain a feeling of what is right from there.

Obviously, reading this book has changed my current shortlist of must-reads a bit:

  1. SCRUM/XP from the Trenches, Hendrik Kniberg (e-book)
  2. Code Complete 2nd Edition, Steven McConnal
  3. Applying Domain Driven Design and Patterns in C#, Jimmy Nilsson
  4. Patterns of Agile Practice Adoption, Amr Elssamadisy (e-book)
  5. xUnit Patterns, Refactoring Test Code, Gerard Meszaros
  6. Domain Driven Design, Tackling Complexity In The Heart, Eric Evans