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 CS

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 use CSLA extensively. There are several benefits; first, I believe that every line of business developer should read Rocky Lhotka's book on Business Objects programming. I've personally found it to be in my top 3 best programming books ever. CSLA is a framework based on this book and using it gives your project access to very high level functionality like n-level undo, validation rules and scalability architecture while providing the details for you. Notice I said "providing" and not "hiding". I've found that the best part of CSLA is that is makes you understand how all of these things are implemented down to the source code without making you reproduce them yourself. You can choose to use as many or few features as you need but I've found that by staying true to the design patterns of the framework, it really keeps you out of trouble. --Byron

Answer 3

I'm a PHP guy. When we started building comparatively large scale applications with PHP, I started researching on lots of application frameworks and ORMs essentially in PHP world, then in Java and .NET. The reason I also looked at Java and .NET frameworks was not to blindly use any PHP framework, but first try to understand what is really going on, and what kind of enterprise level architectures are there.

Because I haven't used CSLA in a real world application, I can't comment on its pros and cons, but what i can say is Lhotka is one the rare thinkers -I'm not saying just expert- in Software Architecture field. Although the name Domain Driven Design is coined by Eric Evans -by the way his book is also great and i humbly advise to read it- Lhotka was applying domain driven design for years. Having said that, whatever you think about his framework, benefit from his profound ideas in the field.

You can find his talks on dotnetrocks.com/archives.aspx and videos from dnrtv.com/archives.aspx (search for Lhotka).

@Byron What are the other two books you liked?

Answer 4

I joined a team where CSLA is mandatory. We don't use the remote data portal which is the only reason I could agree for usage of this framework. I never bought into the idea of CSLA so maybe that's why I have nothing but issues with it, sorry.

A couple of the issues:

I don't need a road block between my code and the .NET framework which is what this framework felt like to me. I had a limited option of list objects, while I just had to ignore the rich list objects in the .NET framework.

Ii is totally ridiculous that we had these read-only lists and then non read-only lists. So if I had to add an item to the list I had to recreate the entire list...are you serious?

Then csla wants to manage my object state which is fine but nothing is really exposed. Sometimes I want to change an object state manually instead of fetching it again which seems like what csla wants me to do. I basically end up creating many properties to expose options csla didn't think I should have direct access to.

Why can't I just instantiate an object? We end up creating static methods which instantiates an object and passes it back...are you kidding me?

Check the framework source code and it looks to heavy on the reflection code to me.

Reasons to use csla:

• the straight .net framework is too powerful for you.

• your developers are not seasoned and can't grasp the concept of patterns then csla will pretty much have everyone on the same page.

  1. I don't need a road block between my code and the .NET framework...I am stuck with these list objects.

Answer 5

A lot of people recommend using Code Generation with CSLA. I'd recommend checking out our set of supported templates as they will increase your ROI immensely.

Thanks -Blake Niemyjski (Author of the CodeSmith CSLA Templates)