My Take on Brad Abrams' PDC RIA Services Talk.

  • Dec 01, 2009 at 11:31 AM
  • Shawn Wildermuth

Silverlight Logo

I've been looking at RIA Services for a long time now. I had the lucky pleasure of being given early access to the bits for what was then called "Alexandria". As most readers of this blog have read, I have had some issues with how RIA Services works. In the mean time Brad Abrams and the team have certainly responded and have made changes to the way that RIA Services works and much of it is for the better. I can see pretty simply how you can use RIA Services to build applications that are really architected well, with true separation of concerns. But there is blood in the water.

I recently had a chance to look at Brad Abrams' PDC video on Building Amazing Applications with RIA Services and Silverlight 4 (CL21). I am perplexed by some of the decisions on the usage patterns of RIA Services implied by the video. I know that there were other RIA Services talks, but since this was by the head of the team, I think this will be used as the exemplar of what developers should write.  And that's unfortunate.

For those of you who didn't see the video, the examples he walks through use the DataSources window in Visual Studio to drag-n-drop RIA Services data onto Silverlight controls. While this is interesting functionality, I think its misplaced. Don't get me wrong, I know there are many companies that need a quick drag-n-drop experience, but in the big picture building applications this way can cost a company a lot of money. My main complaint is that the drag-n-drop experience inserts DomainDataSource objects into the XAML. That means the data logic and UI code are intermingled.  That means you're starting with a tightly-coupled app by default.  The refactoring experience to change that to a loosely-coupled application is not trivial.

By viewing the video, you might be tempted to create your apps in this way but I think for most non-prototype applications, that the overall impact on the cost of building and maintaining the application is going to be much higher than a well-architected application. In some ways it seems like RIA Services is attempting to become the VB6 of Silverlight. While the development environment of drag-n-dropping in VB4-6 helped people make application quickly, it did not help people engineer good applications. Microsoft should not hide good architectural advice inside of Patterns and Practices group, but make it the default way it presents development. Showing off the splashy demo that implies that "its just that easy" makes the presentations feel like an Infomercial instead of real learning.

As I've said for a long time now (in general, not *just* about RIA Services), "Just say no to Data Source controls."





Adam Tuesday, December 1, 2009

Couldn't agree more Shawn. I came to the talk hoping to see something different than the MIX '09 of the same title, but ended up leaving and going to Glenn Block's MEF talk. Much more worth the time. No offense Brad, but I agree with Shawn. We need to move beyond demoing features and start demoing good system architectures. I would love to see Brad's demo app published with an MVVM pattern or using something like MEF etc. Also, where's that Facebook reference app ScottGu mentioned would be available to devs?


Stuart Celarier Tuesday, December 1, 2009

(What Shawn said)++. If you don't talk to your teenagers about sex, then who will? If you don't to talk to your developers about architectural consequences...


Kevin Dockx Tuesday, December 1, 2009

I agree. Although drag 'n drop is nice for quick 'n dirty apps, when you're architecting a SL app with RIA Services, it's NOT the way to go - I never even use the DomainDataSource, not in my projects, not in my Silverlight/RIA Services presentations.

Next to that: I do love what we can do with RIA Services, it's actually my default choice for SL apps now, and I can get it to fit nicely in a MVVM pattern. But let's just stay away from that DomainDataSource-stuff, shall we? ;-)


Andy Beaulieu Tuesday, December 1, 2009

I don't entirely agree on this one Shawn.

I think the Drag/Drop RAD experience is very important for a certain class of applications and developers. MVVM adds in many prerequisites that a lot of developers don't have, and there is no hard and fast defacto pattern yet - we have overlap with Prism, MEF, and homebrew frameworks.

Back in the day a lot of folks who were not even formerly trained as programmers were creating powerful applications based on their business knowledge, not their development knowledge. They used tools such as Visual FoxPro, PowerBuilder, and yes - VB6. I know many scoff at these old school tools now, but you could throw together a form with data access and validation in very short order. And they did it with a RAD drag/drop experience. And in most cases they were quite maintainable with simple old school abstractions and layering.

Sorry I don't mean to fuel a fire, just my 2 cents!


Shawn Wildermuth Tuesday, December 1, 2009


I don't completely disagree...I think the DomainDataSource has its place for RAD, my problem is with message. Its just like the LINQ message early (as it being and ORM instead of a generalized query language). Especially at the PDC where developers are yearning to learn. Do a video series drag-n-drop for quick and dirty apps would be fine, but the first experience shouldn't be the wrong one IMHO.


Tyrone Tuesday, December 1, 2009

I watched the PDC session and it appears that they tried to fit a lot of stuff in an hour and that is probably why the drag-n-drop stuff was featured. Maybe they should state a head of time that this would be a 101 session which would be followed by an advanced session that would be more of a talk about best practices.


David O'Brien Tuesday, December 1, 2009

I agree. Why not lead the way Shawn/ANOther and share the way you would make best use of RIA services.


Richard Reukema Tuesday, December 1, 2009

So we are all in agreement that tight coupling is not good - but then where do we find the demo's with good architectural structure?

It's one thing to critize, but quite another to lead.

Just another 2 cents worth!


Michael Washington Tuesday, December 1, 2009

I think Brad "gets it". The majority of developers will use these tools exactly like he showed it. I think the majority of developers will not use MVVM ect.

When you look at ScottGu's Linq to SQL blogs, that is the exact way the majority of devs that I know are creating apps.

Because it works.


Joe Tuesday, December 1, 2009

It's a valid point. The drag and drop functionality is purely aimed at the demo 'wow factor'.
Frustratingly, I don't think we're that far away from drag and drop IoC/MVVM application building. We need to be able to drag and drop IoC import dependencies and show them on the designer surface alongside the projected bindings.


Shawn Wildermuth Tuesday, December 1, 2009


Don't worry, I am working on a demo now to show my suggestion(s). Luckily RIA Services is tooled to allow it, or will be by RTM.


Adam Tuesday, December 1, 2009

You're right - the hour long sessions are the issue. It would be nice if they had two tracks:

1.) The Show 'n Tell track: short, hour-long presentations where the RIA services, Facebook demo, Intro to Azure, etc. belonged

2.) The Architecture track: I would say 2-4 hour sessions that provide more in-depth system architecture (still using the emerging technologies). Ideally, this is where we'd see MEF, Prism, MVVM, Windows Identity Foundation, DDW, TDD, etc.

I think those are the two basic flavors of attendees; Some people want the cursory overview of the latest and greatest features. Others want end-to-end, prescribed architectural best practices for real-world scenarios.



Shawn Wildermuth Tuesday, December 1, 2009


I think you'll see I do both critize and try to lead. Unfortunately, MS has more eyes on it than I do. If you look at my MVVM and Prism articles, I certainly am trying to help people build real apps.


Steve Wednesday, December 2, 2009

I think Brad's talk was only focused on Ria services generally and not want Ria services + MVVM. Like everything we use to build an entire solution we piece together the parts so like you said Ria Services will now support MVVM. John Papa did a talk about MVVM so people should watch that PDC talk to learn about that and then piece the 2 together as I have. Allot of people will be happy to do as Brad did in his demo and others will want to adopt the MVVM pattern. You are quick to criticsis VB 6 and anything non MVVM but you know what I find maintaining those apps simplier. I have commenced a SL LOB MVVM using prism and even now I find that to create a truely great and rich UI, beyond a simple entry form. I have to put some code into the code behind and then other code I have to put into usercontrols that end up on my form. So when other developers look at the code they now have 3 places to look for code to work out why a certain thing is taking place. I look back and just think this is getting crazy and ultimately the whole test thing that I was trying to achieve is only part of the way there because I still have to UI test as 50% of my code is in user controls and code behind. Also with the commanding story in Silverlight we are using a canned solution for this but soon MS will deliver a partial story in 4.0 So you still need to handle some of that yourself. You kinda have to ask then if the tools aren't really there yet with even SL 4 by trying to implement MVVM with SL are we trying to fit a squart peg in a round whole ?


Everett Wednesday, December 2, 2009

I agree, and I want to know the performance of RIA in enterprise applications. We know it's very important for LOB app, but very few people seem to mention this thing.


Shawn Wildermuth Wednesday, December 2, 2009


I see that people *are* building apps that way. I think the building of the apps isn't the problem with this approach, but the longer-term maintenance. For small internal apps this makes sense (as RAD development) but for larger apps I think a more rigorous approach is needed. For cases where consultants/contractors are doing this way its a nightmare as the spaghetti code is left with no one with knowledge of how it was built. At least with layers its easier to discern what was done.

I don't have a problem with apps being built this way, its the impression that this is the *only* way to build apps that I object to.


Corrado Cavalli Wednesday, December 2, 2009

I totally agree with you Shawn.


David Yack Wednesday, December 2, 2009

Not all military gear needs heavy armor, nor do all apps require the same tooling - real apps aren't as black and white as you suggest in this post, but I think you know that - using a sledge hammer to put in a small nail doesn't make sense - real world applications come in all sizes, shapes, budgets, time constraints among other things - simply suggesting that everyone needs to go buy a sherman tank is crazy.

I like elaborate architecture as much as the next guy so don't get me wrong - I'm not suggesting everyone should use DDS either - I think its a app by app decision.

One area RIA Services has really been enabling early on was small utility applicaitons as an example - these would often never even get an application and would be hacks in access, excel, direct sql etc - RIA enabled it with a decent architecture via the DDS - which isn't nearly as bad as the old data source days with embeded SQL etc you actually have some level of abstraction from the data.

On the other hand, someone building a mission critical system, that already is commited to heavy testing everything DDS isn't a good fit and they have already commited to the overhead of a code only approach

Bottom line you wouldn't use a toothpick to dig a whole if a shovel was sitting next to it, especially if you only had 5 minutes to build or a budget of $50 its all about picking the right tool.

I'd suggest as a community we need to focus more on the pro/con's and helping people be able to make the choice that's right for their specific application.


Michael Iantosca Wednesday, December 2, 2009

I agree with you Shawn drag-and-drop development makes for "good" demos but bad architectures. RIA services looks like it will really encapsulate a lot of the plumbing code but I was hoping to see a well architected solution - or at least a diagram on how you might use RIA Services in a MVVM architecture. I look forward to your demo.
- Michael


Shawn Wildermuth Wednesday, December 2, 2009


I think you missed my point on VB6. I was *not* critizing VB6, but the RIA Services drag-n-drop magic is trying to hide details that I think will bite people in the long run. Note that separating UI from business logic is not *MVVM*. I think separating those concerns is key to maintainability, but not every app should be doing MVVM + Prism. Only large enterprise-sized applications. But the whole DataSource-based development I think will be a problem in the long run. I don't expect everyone to agree, but there are middle grounds here...its not black and white and even the drag-n-drop for small apps makes sense, I just don't like the implication that its the only way.


Shawn Wildermuth Wednesday, December 2, 2009


I think you and I are in agreement. This issue here isn't whether every app should use heavy architecture (clearly it shouldn't) but the perception that *the* way to use RIA is drag-n-drop.


Pop Catalin Thursday, December 3, 2009


Sorry but I have some problems understanding exactly what you mean. What's the "magic" part about a drag and drop operation from Data Sources window? And how is the XAML generated any different than what you would have written by hand? (In my experience it isn't)

Even if you use Blend you "drag & drop" various things from the toolbar onto your canvas.

Building UIs using drag & drop is a technique used for over 20 years.

It's not the drag & drop operation that creates problems it's the code that is generated by that operation and most importantly the code you write afterward.

Even in Winforms there were no problems if you created the UI using drag & drop (because that only creates the databound controls), the problem was when you started writing application logic directly behind click events.

And also, a RIA Services App is already tiered by design, using the RIA model you write the application logic on the server, and on the client the only thing remaining is presentation logic. Basically the entire Siverlight client is simply a presenter (at least that seems to be the goal).

Silverlight can't be compared to Winforms or VB6 in this respect because of the reason stated above, you only write presentation logic on the client, the application logic is on the server.

Cata P.


Rob Eisenberg Thursday, December 3, 2009

I sometimes wonder what would happen if Microsoft spent as much time thinking about text-based DSLs as they do drag and drop. Personally, I feel that DSLs can actually give us the productivity of RAD, enforce sound architecture and improve maintainability. But it's much more difficult to build something like that and it can only be successful if based on real-world application scenarios...

In any case, I'm looking forward to your sample. I too was disappointed in what I saw in a number of the PDC talks. Microsoft is talking the MVVM talk but not walking the walk...


henrik Thursday, December 3, 2009

Hello !!

May I address a question regarding RIA to you, in the sample discussed, sql server 2008 is used;Do I have to use sql server 2008 when using visual studio 2010 for Ria apps????



Shawn Wildermuth Wednesday, December 16, 2009


The problem isn't the generated XAML its the data source. Mixing the data layer in the UI tends to be a maintenance nightmare.


Shawn Wildermuth Wednesday, December 16, 2009


I agree about DSLs but with Oslo's bending away from the DSL, I think its going to be a long time before the MS stack 'gets' DSLs.


Shawn Wildermuth Wednesday, December 16, 2009


RIA doesn't require SQL 2008.

Leave a Comment