I have been asked several times what the community can do to help get WCF RIA Services open source. After doing some research into how open source works, and reading articles like this one, it is clear that just asking Microsoft to open source something is not enough. We need to have to have a vision and a plan.

What I am going to layout here is my vision for what an open source WCF RIA Services project would look like. I have development split into three main branches which I have numbered as 4.2, 5.0, and 6.0. We are starting at 4.2 as the current closed source WCF RIA Services has a 4.1 version number.

4.2 will be the initial open source release of WCF RIA Services. Here we will fix bugs, add M2M support, change a bunch of internal code to public, and other things which do not break backwards compatibility.

The version 5 branch of WCF RIA Services will be where cross-platform work will happen. My position is that supporting the same API across all platforms is more important than maintaining the current Silverlight API as-is. Accordingly, there may be breaking changes within the Silverlight client and/or server parts of WCF RIA Services to create a consistent API. If you want to contribute breaking changes to WCF RIA Services then the 5 branch is where you will want to be.

The 6 branch is targeted to be released along with Visual Studio v.Next and the Roslyn compiler. The focus of the 6 branch will be on integrating Roslyn into WCF RIA Services where it makes sense. For example, Roslyn will enable client side POCO object to be used as entities instead of the current code generated entities which inherit from Entity.

This branch is where I am going to put things that may not end up in one of the main releases. There is a lot of wild things that could be done in WCF RIA Services and not all ideas may turn out to be good ones.

The Plan

So, that in a nutshell is my vision for WCF RIA Services. As you can see, each branch has a page linked where more information about each branch can be found. What you can do is provide additional ideas in the comments of this blog post. I will copy them into whatever branch page I think makes the most sense.

If/when WCF RIA Services is open source my main priority is going to be the 5.0 cross-platform branch of development. Merijn de Jonge , the developer of M2M4RIA on Codeplex, has already indicated that he would be willing to work on adding M2M support to the 4.2 branch and there a few things I want to get done in the 4.2 branch like change notification before I get too deep into the 5.0 branch.

I don't think development on the 6.0 branch will start until late 2013 after the 5.0 branch is completely stable and more features have been added to the 4.2 branch.

The original User's Voice site for WCF RIA Services seems to be gone, luckily the Internet Archive Wayback machine has a copy. I thought it might be interesting to go through the list of the issues from the first page that have not been completed yet and see what I would do in my own fork of WCF RIA Services if it were open sourced.

Support data change notifications from the server

I have a proof of concept design for a change notification system that uses SignalR. The DomainService needs a tweak to make it easier to get the primary keys of each entity on the server.

Windows Phone 8, WinRT, Mono (Droid and IOS), and WPF support are all a top priority and, I think, doable. However, I would not be porting the DomainDataSource as it is too specific to Silverlight.

Fluent-API based metadata (to replace buddy classes)

This is already an active project being spearheaded by Merijn.

EntityQuery<T>.Select() to project entities from the RIA Clients without creating DTOs at the server

This is very unlikely as it goes against the basic design and purpose of WCF RIA Services.

Support more of OData

In general, I think replacing the current WCF based DomainService with a WebAPI based "DomainController" would be a good direction to go in. However, WCF RIA Services is not WCF Data Services and attempts to make either one of them more like the other is misguided.

Ability to Include Navigation Properties Based on Many-to-Many relationships

The M2M4RIA project on CodePlex would be rolled into WCF RIA Services itself. I am not sure exactly what that would look like but I know Merijn is ready to handle it.

A visual plugin for VS to manage domain services

This is very unlikely, I would be moving away from visual editors and towards direct code editing. If somebody else wants to tackly this then I would happily add it to my version.

Offline support in RIA Services

An open source WCF RIA Services would have a much improved version of RiaServicesContrib.EntityTools which does support complex types and composition. Those new hooks should allow the easy creation of rich offline capabilities.

MVVM support in project Template

RIA Services support for AJAX (HTML clients)

I think HTML5 support will be important, figuring out what that means is the difficult part.

Propagate authorization/role metadata from server to client so that it can be used for building authorization-specific UI; e.g. admin sees additional named update methods that a user does not.

Honestly, I have no idea what that even means.

Paging support without requiring LINQ backend (e.g. sprocs)

This is a maybe. To some degree I feel that user defined table valued functions would accomplish the same goal without needing any changes made. I do have a few ideas here which I may try out, however it may wait until there is a user who is willing to be the guinea pig.

Transaction support from client

Same as paging support, I have some ideas here on how to package multiple SaveChanges calls from multiple DomainContexts into a single communication with the server but no real proof of concept.

RIA Service support for ORMs besides EF

This request was about adding support for more ORMs to the DomainService wizard. Honestly, thinking long term, I am not sure if the DomainService wizard is going to keep working for EF.

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.

Today, Microsoft officially and publically revealed that development of Upshot.JS and DataController, the spiritual if not actual WCF RIA Services V2, will not continue at Microsoft.

With WCF RIA Services V1 joined at the hip with Silverlight, that means that WCF RIA Services is in whatever category you consider Silverlight itself being in. Personally, I am still writing new Silverlight applications and using WCF RIA Services. I think that will continue for a few more years before my client get ready to start moving off of Windows 7 as their primary platform. At that point I will probably start porting our Silverlight applications to WinRT.

So, what does this news mean to us?

Microsoft still supports WCF RIA Services.

I still support WCF RIA Services.

I still expect WCF RIA Services to get EF5 support, that falls under Microsoft's responsibility to support the product they have already released.

What about the future:

I am pushing to get WCF RIA Services V1 open sourced. If that happens I will be porting it over to WinRT and making large scale improvements to the Silverlight client.

If you need something now to port to WinRT, or you need something that has a bit more umph behind it as far as support goes, I would recommend looking at IdeaBlad DevForce. It is similar to WCF RIA Services in many ways but it supports almost every platform including WinRT.

As far as Upshot goes, if WCF RIA Services is open sourced then I will be looking at alternatives to improve HTML5 support for WCF RIA Services. For example, IdeaBlade has an open source alternative to Upshot.js named BreezeJS. I haven't had a chance to check it out yet but it may be a candidate for later adoption.

I am also strongly considering replacing the DomainService with the DataController but I will probably change the name to DomainController.

Is there anything the community can do?

Yes, put pressure on Microsoft to get WCF RIA Services open sourced. My hands are tied until that happens.

6 Month Update

It has been a little over 6 months since this blog entry went up, so I decided to update it for anyone new happening upon it. Newer blog entries contain the development plans for an Open RIA Services. The current status is that Microsoft doesn't need any convincing, we are just waiting on the lawyers.

Two big announcements today. First, the old RiaServicesContrib.dll file has been replaced with RiaServicesContrib.EntityTools.dll and is now available as a NuGet package. The package name is RiaServicesContrib.EntityTools. Hope that is easy to remember.

The other news is that RIA Services Contrib has a new scaffolding system for EF 4.1.

Soon after WCF RIA Services support for EF 4.1 was released, Rudi Larno released a scaffolding system for building the DomainServices based on the EF model. Unfortunatly, Rudi doesn't have time to maintain what he built so I am taking it over for him. Today I added the scaffolding code to the RIA Services Contrib project on Codeplex and published it on NuGet.

The scaffold is not exactly the same as what Rudi was using. When you create a DomainService using the scaffold you may need to add a new using statement with the namespace where your POCO entities are. Also, I modified what is generated to match the snippet code supplied by Microsoft.

To install the scaffolder

1) In the Package Manager Console select the package that will contain the DomainService2) Type Install-Package RIAServicesContrib.EntityFramework.Scaffolding and push enter

To use the scaffolding system, in the PackageManagerConsole type in the following command line:

One of the really interesting things Varun provides is a snippet to help setup the DbDomainService since the Wizard will not be available until SP2 is released. After using the snippet I am not sure what we all did without it.

To help make it even better, I have made my own modifications and, since Varun released the original under MS-PL, I am adding the snippets to RIA Services Contrib. For now they are available at the bottom of this post.

I actually have six different snippets for both VB and CS covering both DbDomainService and LinqToEntitiesDomainService.

I think Kyle is doing some really interesting things with this code, but I think I prefer how John's original code used ObservableCollections (which were really EntityLists) instead of how Kyle is casting everything to IEnumerable or ICollection. What I will be creating next is my version of the Book Club which will be a mix of John's code, Kyle's code, and some completely different concepts that I am working on.

Since this blog first opened in June of 2009 it has been named The Elephant and the Silverlight. The name came from John Godfrey Saxe’s The Blind Men and the Elephant. At the time, WCF RIA Services was all about Silverlight and people were arguing about just what WCF RIA Services and Silverlight were. The name made sense at the time.

However, this blog has really always been about WCF RIA Services, Silverlight was just along for the ride. Here in 2011, WCF RIA services isn’t just about Silverlight anymore. With the release of RIA/JS, HTML is joining Silverlight as a fully functional client of WCF RIA Services. While I am still primarily a Silverlight programmer, I will be expanding my coverage and my community support efforts to include the HTML platform. So, the name of this blog is changing to just The RIA Services Blog to reflect the new platform agnostic approach I will be taking around here.

So, to the HTML JQuery programmers out there, welcome to my blog. Please cut me some slack, it will take me a little while to get fully up to speed on this whole JQuery thing but I am eager to learn.

To my fellow Silverlight developers, don’t worry I am not going anywhere. I still strongly believe in Silverlight and most of my development efforts will continue to be in the Silverlight space. I think there is an opportunity with RIA/JS for us Silverlight developers to show how easy it would be to create fallback HTML versions of our Silverlight applications so that we can get the best of both worlds. Silverlight for the platforms that support it, and HTML for the platforms that don’t. With tools like RIA/JS, maybe this dual approach will not mean actually writing the application twice.

Back on December 2, 2010 John Papa gifted the community with an excellent example of proper Silverlight architecture and I have been recommending people watch the video, download John’s code, and follow the pattern to create their own applications.

Over the last couple of weeks I have started a new project at work and this time I have decided to follow the example I have given to others. This experience is showing some places where my own preferences diverge from John’s so I have decided to share my changes with the community. I am taking the experiences in my own project and porting them into John’s project. I am not going to dump all of my changes in at once, I am going to be making gradual changes across at least three blog posts. In this first post I will be integrating Marlon Grech’s MEFedMVVM library into John’s code. Over the new two blog posts I will be changing the DataServices to use ICollectionView instead of EntityList and in the third post I will be changing the design time DataServices to use the actual RIA Servics entities instead of separate design time entities. Kyle McClellan on the RIA Services team at Microsoft has come up with something better then what I was working on for parts 2 and 3. Check it out at http://blogs.msdn.com/b/kylemc/archive/2011/04/29/mvvm-pattern-for-ria-services.aspx. I will be posting up a MEFed up version of Kyle's project.

MEFing up the code

Out with the old

I am going to be gutting John’s provider and locator code to replace them with MEFedMVVM replacements. This means that I first deleted the following classes:

Assets\ObjectResourceDictionary

DesignServices\DesignServiceConductor

Services\ServiceProvider

Services\ServiceProviderBase

ViewModels\ViewModelLocator

Then I removed the following line from the App.xaml

<ResourceDictionary Source="Assets/ObjectResourceDictionary.xaml"/>

MEFing up the views

Now I was ready to put MEFedMVVM into place. First I coped MEFedMVVM.SL.dll into the Lib directory of the project and added a reference. Then I needed to add MEF itself which is done by referencing System.ComponentModel.Composition

Then in BookView.xaml and EditBookWindow.xaml John’s original locator code was replaced with:

meffed:ViewModelLocator.SharedViewModel="Book"

In CheckoutView.xaml the locator code was replaced with:

meffed:ViewModelLocator.NonSharedViewModel="Checkout"

The use of SharedViewModel and NonSharedViewModel mirrors the original design that John used. BookView.xaml and EditBookWindow.xaml will share the same instance of the ViewModel while CheckOutView.xaml will get a new instance of its ViewModel every time it loads.

MEFing up the ViewModels

I registered the BookViewModel with MEF using the MEFedMVVM ExportViewModel attribute

MEFing up the DataServices and PageConductors

Last step was registering the DataServices and PageConductors. These were registered with MEF using MEFedMVVM’s RegisterService attribute which allows us to set a ServiceType of Runtime, DesignTime, or Both. By registering the DesignBookDataService and the DesignPageConductor as having a ServiceType of DesignTime we will get the same design time data support that John had in the original version.

Conclusion

I think the MEFedMVVM way of doing things is both simpler and more powerful than John’s original method. It greatly reduces the amount of classes needed and makes it much easier to add new Views, ViewModels, and DataServices to your solution. Here is the ZIP file containing the modified solution: