Does WCF RIA enforce bad design?

Question

I have been dabbling in WCF RIA with Silverlight for the past few weeks and I am finding it very difficult to generate well-designed software using it. My impression is that it's a tool that's best used for "rapid application development", prototyping and fancy-looking demonstrations.

As an example, to make the most of RIA I find you pretty much have to take a dependency on your data model from end to end. The best-sounding features of WCF RIA (like end-to-end validation and EF integration) require you to present your Entity Framework data model pretty much as-is, all the way down into your presentation layer. This precludes designing your software using a Service Layer pattern, data mappers or DTO's. I also find myself struggling (so far to no avail) to create an application with a true Domain Model due to limitations in EF.

The code generation stuff is nice and I could see it saving me time, except that it doesn't support such basic scenarios as many-to-many relationships. This causes me to have to expose even more of my database implementation details through EF by exposing the intermediate foreign key table.

On top of these issues, WCF RIA is notoriously almost impossible to test. DomainContext classes are not hidden behind interfaces and doing so is extremely difficult due to change tracking and other subtleties. In every single case I have seen in the wild, ViewModels end up taking direct dependencies on the DomainContext implementation. Even when this dependency is constructor-injected it's meaningless because it can't reasonably be mocked.

So I guess my question is two-fold: Does WCF RIA enforce bad design? If so, are there any reasonable workarounds that don't end up with me losing most of the advantages of the platform? And if not, can someone point me to some literature that shows how to generate good designs based on tried-and-true patterns using WCF RIA?

Answer 1

You might re-phrase the question as "Can I have my cake and eat it?".

Having been coding for some 30+ years I have seen this cycle many times:-

• 3rd Generation Language is too flexiable we are repeating ourselves doing the same things over. What we need is 4th generation language or framework the cuts out all this repeatition.
• 4th Generation Language or framework is too restrictive it forces me to find ugly workarounds and "enforces bad design" in my specific project. What we need is a more flexiable lower level language that lets us do exactly what we want.
• Yet another 3rd Generation Language is too flexiable .... cycle repeats.

Tools such as RIA, Lightswitch, WebMatrix etc are in the 4th Generation camp. They by design enforce a specific way to doing certain tasks in order to eliminate repeation and to allow developers bang out working stuff quickly. Developers trade ideal design for speed of developement. This tradeoff is as old computing itself.

So to answer your question, no you can't have your cake and eat it. You either do things their way and use the RIA WCF service or you do things your way and create your own WCF services. There is some middle ground (as always) where you can use some RIA WCF then jump through hoops making it do what you want.

BTW, EF does offer considerable abstraction (albeit with a lot effort) between the model it ends up presenting and your actual Database schema. It does for example allow you to present a many-to-many relationship without an intermediatory class.

Answer 2

The answer to this question is "No". It doesn't enforce "bad design". It's just a specific tool in your toolbox and it's designed to solve a particular problem. You sound like someone who is trying to take a hammer and use it to drill a hole, and saying, "Why doesn't this thing make a nice hole in my wall?" Ummm.. Because it's a hammer man. It's designed for a different job...

A lot of our skills as developers is in figuring out the right tool to use for the job. Silverlight and RIA have their uses, but they are not a magic silver bullet.

I think you're looking at the technology with the wrong goals in mind. And I say this as a guy who is a big fan of TDD, MVC, etc. I've written my share of apps that use DTO's, Repositories, layers, abstractions, etc... I've also written quite a bit of Silverlight and RIA in the past few months.

Anthony said it well: Silverlight and RIA are designed to "eliminate repeation and to allow developers bang out working stuff quickly." I don't think Silverlight and RIA are desgined for giant enterprise apps with loads of business logic tucked into the VM - something where you need unit testing and TDD to drive the process... This is the wrong tool for THAT job.

I decided to look at some of my ViewModels in some recent projects in Silverlight. Here's what I found: Everything I'm doing in the VM is pretty much delegating to something Silverlight already does for me: databinding, observing property changes, querying data contexts, saving changes to a data context, validating entities and notifying the GUI, etc.

Silverlight and RIA already do these tasks for me. I am just delegating calls! If I were to write a unit test, I'd be testing Silverlight and RIA - not my domain logic! I don't need to test the framework - I assume MS knows what they're doing.

If you have enough complexity to warrant DTO's, data mappers, service layers, etc... Then you probably need to think about something other than Silverlight and RIA. Know what I'm saying?

The right tool for the job man. Choose the right tools.

Answer 3

These links might help you.

Using DTO's

Unit testng

Architecture