New Silverlight app. MVVM. RIA Services vs CSLA

Question

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?

Answer 1

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.
http://rationalgeek.com/blog/post/WCF-RIA-Services-Silverlight-Guild.aspx

Answer 2

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.

Answer 3

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