Another 2 days of reading and watching demos and here we go.

For my enterprise LoB Silverlight app I'm going to use:

  1. Prism for UI aspects and modularity.
  2. MVVM pattern (using Prism)
  3. ??? to bring data over and validations...
  4. Entity Framework for Data access
  5. SQL Server for data

Ok, main dilemma is #3. If I won't use any framework then I will have to figure out how to do all CRUD stuff myself. I can do RESTful WCF, I can do SOAP. All that == MANUAL coding.

I can do RIA Services. I kind of see what it does and it is nice for direct match with my data layer BUT it is not that great if there will be lot of business logic. Where would I put it? In my ViewModel? Another question is how those services maintained. Once I generated it - I should maintain them by hand if data changes?

I also found CSLA which seems to be nice on one hand but receives lot's of critique.. CSLA will allow me to write business logic and shape object as I needed and than I can pass it "through" ViewModel and all is well.

Something tells me that RIA Services will be much quicker to write. Also, I like the fact that I don't have to include extra dependencies.

There is no blogs or mentioning of RIA Services since 2010. Is it going under table? Not widely accepted? Not scaling well for big apps?

I'm trying to decide which one I need to bet on. CSLA or RIA Services. OR?

3 Answers 3


I have recently been working on some line-of-business Silverlight projects. For one we used straight WCF and did all the CRUD, state tracking, entity relationship, etc. ourselves. For the second project we are using RIA Services and had it manage all of that stuff for us.

However, we did NOT have RIA Services directly generate services based on our ORM model. We had a layer of interfaces and "dumb objects" in between. So we had a distinct data tier, business logic tier, and service tier. RIA Services was only involved at the service tier.

If you are going to use RIA Services, I recommend limiting how much of the layers of your application you let it influence. It does force you down certain paths as far as design is concerned, so the more you contain it the more flexibility you will have. This advice is probably sound for CSLA as well. If you are going to "bet" on a particular framework, hedge your bet as much as possible.

In summary, RIA Services will definitely save you time, but it does limit your flexibility a bit compared with raw WCF. And it has some kinks and weaker areas that still need improvement.

I haven't worked with CSLA, but I have seen Rocky Lhotka give talks on it several times so I know the basics. It seems like a solid framework. However, the main disadvantage it will have compared with RIA Services is that it isn't directly from Microsoft, so CSLA won't mesh as cohesively with other MS stuff as much as RIA Services will. Also, in the long run I'm guessing it will be easier to find people that know RIA Services versus people that know CSLA.

If it helps, I gave a talk on RIA Services you can find the presentation and some sample code on my blog.

  • When you mentioned layers you used - you put them in correct order? As Data->Business->RIA ? So, there was NO Business logic on client? I thought about doing Data->RIA(+Business)->VM That will marry me to RIA. I can separate Business logic and move it to VM but not sure that is a good approach either. I kind of wanted RIA for authentication and validations it provides.
    – katit
    Commented Aug 12, 2011 at 12:38
  • Correct. Data > Business > Services (RIA) > UI. I won't say there was no business logic on the client, but that was the goal that we tried to achieve. I'm sure corners were cut in places where pragmatism won over idealism. Commented Aug 16, 2011 at 12:15
  • 3
    "the main disadvantage it will have compared with RIA Services is that it isn't directly from Microsoft, so CSLA won't mesh as cohesively with other MS stuff as much as RIA Services will" Not true, Rocky has had input into MS as they develop stuff. I think he's one of the main reason you can bind objects in every UI technology instead of only DataSets / DataTables. I use Csla, its designed to integrate very smoothly with everything from WinForms to MVC3 to Silverlight to WP7 to Metro.
    – Andy
    Commented Oct 22, 2011 at 1:28

I am working on a WPF and Silverlight (two separate clients) project that makes heavy use of the CSLA.NET Framework. We've had very little trouble from the CSLA.NET Framework which is mature, very well tested, has excellent support from Rocky and the community, and provides solutions to a lot of the problems one has developing modern .NET applications (data-binding, data-access, validation, authentication, to name just a few).

The CSLA.NET is not perfect, perhaps in that it doesn't fit perfectly into the message bus type architectures; but if your goal is a line-of-business application sat on top a database, then CSLA.NET is a sensible choice. Perhaps another issue is the learning curve but the educational material is comprehensive and well written.

  • I think your answer is spot on. Csla can be used in message bus / batch processing scenarios, but its mainly designed for the interactive application (including the web), giving users feedback immediately when they enter an invalid value, etc.
    – Andy
    Commented Oct 22, 2011 at 1:30

We're about 1.5 years into a 3 year project using CSLA, Prism, TSQL and Silverlight. Given the chance, I'd toss CSLA out as quickly as possible. One of the biggest problems I have with CSLA is that it tries to do everything. If you watch Rich Hikey's talk on Simple vs Easy (http://www.infoq.com/presentations/Simple-Made-Easy) you'll notice he talks about "complecting" things. That is, entangling code so that a single object is responsible for more than one thing.

CSLA violates this principle (and that of SOLID) left, right, and center. You basically end up with a situation where your business rules are in your data transfer objects. You end up using the same object that you populated with DB data (either directly from EF or via DTOs), and that same exact object ends up on the client being bound to the UI. Or you can wrap them in View Models, if you wish, but that just adds more and more complexity.

On top of that you're locking your client software into a .NET language. If in the future you want to provide service feeds or simply access your data from JS and HTML, you're suddenly forced to wrap hundreds of lines of code to present to these different platforms.

Keep it simple...have your web server spit out JSON...have you client and servers completely de-coupled (share code files if desired, but don't couple them). The simpler your code is, the easier it will be to fix bugs, understand what's going on, and keep everything under control

  • I picked DevForce and extremely happy. I have JSON service for some functionality (other clients)
    – katit
    Commented May 12, 2012 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.