Is WCF RIA Services ready for the Enterprise?
Today Microsoft released the WCF RIA Services Beta, it’s now on top of WCF and by default uses binary data end points and data contract serialization. By using binary data end points we will get better performance and make the data sent over the wire smaller (The other preview versions uses pure JSON). WCF RIA Services is a great framework for Rapid Application Development (RAD) of 2-tier applications. Based on the new changes to the WCF RIA Services it’s defiantly ready for the Intranet and small applications, but how about the Enterprise. First of all if you uses the Entity Framework or Linq to SQL Domain Services, it’s not ready for the Enterprise and will never be, IMO, because when we use it it distribute DAL types to the client. They are useful for small data driven applications. BUT! WCF RIA Services with the DTO (Data Transfer Object) support will make it closer to be ready for the Enterprise, but is that enough?
It’s complex to build RIA (Rich Internet Application) and require a lot of plumbing. This is something WCF RIA Services is trying to solve. Just remember there is a reason why things are complex, and what every framework developers are trying to do, is to hide the complexity by adding a new level of abstraction. The thing is, the complexity is still there. At first I was skeptic about WCF RIA Services, but it was because the very early previous wasn’t that good, it was ok, good ideas but works had to be done. Now after almost 2 years it starts to look like something promising.
I have notice several of developers using .WCF RIA Services and because it’s so easy to use, they seems to forgot about the network. What the WCF RIA Services Team have struggle with, is to make sure developers should be aware of the network. I know that even how much they try, some developers will use it in a wrong way. That is nothing they can do anything about. But is that so bad? NO! It gives the people that use it in the right way job opportunists ;)
I wrote that WCF RIA Services with its DTO support will make it closer to be ready for the Enterprise and the uses of EF and L2S Domain Services are not a good choose when it comes to build Enterprise RIA. There are actually one advantage of using the EF and L2S DomainServices, and that is the way of passing a query from the client to the server. The query will be used when EF and L2S are querying the database (as far as I know, I hope it does at least ;)). It will results in less data sent from the data source. When using DTO the query will take place after we retrieve all the data from our DomainService query methods. But still on the server. But the good thing is that there is a solution to make sure the query also takes place when we query our data source and that is by overriding the DomainService Query method, it has the description of the query passed from the Client. But we had to interpret it and transform it to a query which can query our domain model.
It looks like developers loves the data annotations added to WCF RIA Services. The validation part is great when it comes to the uses of EF and L2S Domain Services, because the DAL types are generated from the tools (hmm, thinking of the Devils is in the tools ;)), and it’s “hard” to add validation to it. In that case with WCF RIA Services we can use annotation to add validations, which will be available both on the client and the server. Isn’t that great? DTO also support validations buy adding annotations. You have to have in mind, that this validation can’t be tested with Unit Test, it’s the Framework which will execute it. But you also have to remember that DTO is just what is says an object which transfers data. On the client-side we may use a ViewModel which will handle the validation instead.
Back to the main question, is WCF RIA Services ready for the Enterprise? If I say Yes, it may be a lie, if I say No, it’s definitely a lie. I think it’s ready, or at least I would give it a try. I think the team have made a great framework, I will with no doubt recommand it to others.