Does anyone have any real-world experience of CSLA

Question

The main web application of my company is crying out for a nifty set of libraries to make it in some way maintainable and scalable, and one of my colleagues has suggested CSLA. So I've bought the book but as :

programmers don't read books anymore

I wanted to gauge the SOFlow community's opinion of it.

So here are my questions:

1. How may people are using CSLA?
2. What are the pros and cons?
3. Does CSLA really not fit in with TDD?
4. What are my alternatives?
5. If you have stopped using it or decided against why?

Answer 1

After reading all the answers, I've noticed that quite a few people have some misconceptions about CSLA.

First, CSLA is not an ORM. How can I say that so definitely? Because Rockford Lhotka has stated it himself many times in interviews on the .NET Rocks and Hanselminutes podcasts. Look for any episode where Rocky was interviewed and he'll state it in no uncertain terms. I think this is the most critical fact for people to understand, because almost all the misconceptions about CSLA flow from believing that it is an ORM or attempting to use it as one.

As Brad Leach alluded in his answer, CSLA objects model behavior, although it may be more accurate to say that they model the behavior of data, since data is integral to them. CSLA is not an ORM because it's completely agnostic about how you talk to your data store. You should use some kind of data access layer with CSLA, perhaps even an ORM. (I do. I now use Entity Framework, which works beautifully.)

Now, on to unit testing. I've never had any difficulty unit testing my CSLA objects, because I don't put my data access code directly into my business objects. Instead, I use some variation of the repository pattern. The repository is consumed by CSLA, not the other way around. By swapping in a fake repository for my unit tests and using the local data portal, BOOM! it's simple. (Once Entity Framework allows the use of POCOs, this will be even cleaner.)

All of this comes from realizing that CSLA is not an ORM. It might consume an ORM, but it itself is not one.

Cheers.

UPDATE

I thought I'd make a few more comments.

Some people have said that CSLA is verbose compared to things like LINQ to SQL and so on. But here we're comparing apples to oranges. LINQ to SQL is an ORM. It offers some things that CSLA does not, and CSLA offers some things L2S does not, like integrated validation and n-tier persistence through the various remote data portals. In fact, I'd say that last thing, n-tier persistence, trumps them all for me. If I want to use Entity Framework or LINQ to SQL over the net, I have to put something like WCF in between, and that multiplies the work and complexity enormously, to the point where I think it is much more verbose than CSLA. (Now, I'm a fan of WCF, REST and SOA, but use it where you really need it, such as when you want to expose a service to third parties. For most line-of-business apps, it isn't really needed, and CSLA is a better choice.) In fact, with the latest version of CSLA, Rocky provides a WCFDataPortal, which I've used. It works great.

I'm a fan of SOLID, TDD, and other modern software development principles, and use them wherever practical. But I think the benefits of CSLA outweigh some of the objections of those orthodoxies, and in any case I've managed to make CSLA work quite well (and easily) with TDD, so that's not an issue.

Answer 2

We started using CSLA because we thought it would help with our model layer. Was sort of overkill and mostly all we use now is the SmartDate class, just because we're already linked to the library.

We thought the validation interface would really help us enforce business rules but it didn't work well with WCF and serialization (we're still stuck on version 2.0.3.0, so things might have changed).

Answer 3

I'm new to CSLA but I understand the concepts and I already understand that it's not an ORM tool so quit beating that damn drum folks. There are features of CSLA I like but using them feels a bit like there is a magician behind the curtain. I guess if you don't mind not knowing about how it works then you can use the objects and they work fine.

There is a large learning curve for beginners and I think it would benefit greatly by having 5-15 min. videos like Microsoft has for learning the fundamentals. Or how about releasing a companion book with the code instead of getting the code released and taking months to get the book out? Just sayin Mr Lohtka... We started building our stuff before the book and I struggled the whole time. But like I said, I'm new to it.

We used CSLA. We made our objects fit their mold then used 10% of what the framework offered. Object level undo? Didn't use it. NTier flexibility? Didn't use it. We ended up writing enough business rule code that I thought the only thing we were getting out of CSLA was complexity. Some "long in the tooth" developers that know the framework used it as their hammer because they had a nail that needed hitting. CSLA was in their belt and my guess is a lot of proponents of the framework see things from that perspective too.

I guess our seasoned developers are happy because it all makes sense to them. I guess if your organization doesn't have newbie programmers and you guys get bored by writing efficient and simple POCO objects with well formed patterns, then go for it. Use CSLA.

Answer 4

I last tried to use CSLA in the stone age days of VB6. In retrospect, it would have been more effective if I had used code generation. If you don't have effective code generation tools and a strategy for fitting them into your workflow, they you should avoid frameworks like CSLA, otherwise the features you get from CSLA won't make up for the amount of time you spend writing n lines of code per table, n lines of code per column, etc.

Answer 5

I've used CSLA.NET in few projects now, it was most successfull in a windows forms application which has rich databinding compatabilities (which asp.net application's don't have).

It's main problem is the TDD support like people have been pointing out, this is because of the black-box like behaviour for the Dataportal_XYZ functions and it's inability to allow us to mock the data objects. There have been efforts to work around this issue with this being the best approach