Oct
4
2012

Musings on WCF RIA Services #1: The DomainDataSource

Frame the problem for me 

Today I tweeted this:

WCF RIA Services was actually very mature, the DDS just always was and always will be a bad idea.

On further reflection, that statement is not correct. It isn't the DomainDataSource that was the problem, it was the perception of the DomainDataSource's importance that was the problem. To restate the issue:

Thinking of the DomainDataSource as the primary component of WCF RIA Services is a mistake.

For most of the demos and walkthoughs that originally showed off the capabilities of WCF RIA Services were about the DomainDataSource. The focus was on rapid application development and creating applications using very little actual code. If you are trying to show off how good Silverlight can be at creating LOB applications and you only have an hour to present it was a wonderful thing. The problem is that these demos tended to undersell what WCF RIA Services as a whole is capable of doing and oversell what the DomainDataSource is capable of.

What is the DomainDataSource?

The DomainDataSource is an on-screen component that supplies single-entity-type bindings for simple data viewing and editing scenarios. It is really good at supplying grid controls with data and for master-detail scenarios where a grid control is paired with a DataForm control. In short, it is really good at creating the same type of simple business applications that ASP.NET MVC is good at creating.

The DomainDataSource is not very good at multi-entity scenarios and should not be used for binding to the ItemsSource of controls within a DataForm (i.e. ComboBoxes). The DomainDataSource is also designed for safety above all else. For example, in a paging situation the DomainDataSource disables paging if there is any unsaved modifications within the DomainContext. This is to prevent modified data from being accidentally removed from the cache without being saved. For the basic, no-code type of application that the DomainDataSource was designed to support, such safety considerations are very important. Unfortunately, this means that the DomainDataSource is too inflexible to be used for more complicated, Line of Business type applications.

If the DomainDataSource was not useful for large scale LOB applications, what was the point of creating it?

At the time that WCF RIA Services was first shown to the public as Alexandria, Silverlight was still looked at as a Flash and HTML replacement. The idea of using Silverlight as important tool for creating LOB applications was in its infancy. That happened later as Windows Forms refugees like myself who has been forced to suffer under the yoke of ASP.NET Web Forms for several years looked at Silverlight as the way out of our misery. At the time I remember being asked by Microsoft employees on the Silverlight team why programmers like myself were interested in using Silverlight to create LOB applications. From their perspective, they just needed a way to create simple business applications, not large scale LOB applications, and the DomainDataSource was really good at doing that.

Wait, you lost me, if the DomainDataSource was the main product of WCF RIA Services, how could thinking of it as the primary component of WCF RIA Services be a mistake? It was the primary component!

The history of Silverlight is littered with intentions to create one thing resulting in the creation of a completely different thing. Silverlight started off as a replacement for Flash and HTML, it ended up replacing Windows instead. I highly doubt that WinRT would be where it is today if Silverlight hadn't blazed the trail to begin with.

In the case of WCF RIA Services, the programmers and arcitects at Microsoft who were assigned to the project were simply better at their jobs then they needed to be and the back end of WCF RIA Services was over designed. While the DomainDataSource is of limited utility in complicated Line of Business applications, the back end code that was written to support the DomainDataSource does not have that same limitation.

OK, sum it up for me

When WCF RIA Services first came out, the DomainDataSource was the star component that needed to be showed off. As time went by, LOB development became a really important part of Silverlight development, the importance of the DomainDataSource waned, and the importance of the code components of WCF RIA Services became more important. The problem was that the original demos, documentation, and presentations given on WCF RIA Services were still all about the DomainDataSource which was no longer the most important part of WCF RIA Services. Learning how to use WCF RIA Services correctly came from reading my blog, John Papa's presentation at Silverlight Firestarter, the blogs of the RIA Services team at Microsoft, and the forums at Silverlight.net where I constantly repeated the "Do not use the DomainDataSource" refrain over and over again.

That is why we are in the positon we are in today, to most of the community WCF RIA Services is still thought of as the DomainDataSource, a simple control only good for simple applications. In future musings, I am going to look at the rest of WCF RIA Services and what it really is. Along the way, I hope to redefine just what WCF RIA Services is.

Month List