Does anyone have any real-world experience of CSLA? [closed]

Question

Before I specifically answer your question, I'd like to put a few thoughts down. Is CSLA right for your project? It depends. I would personally consider CSLA for desktop based applications that does not value unit testing as a high priority. CSLA is great if you want to easily scale to an n-tier application. CSLA tends to get some flack because it does not allow pure unit testing. This is true, however like anything in technology, I believe that there is No One True Way. Unit testing may not be something you are undertaking for a specific project. What works for one team and one project may not work for another team or other project.

There are also many misconceptions in regards to CSLA. It is not an ORM. it is not a competitor to NHibernate (in fact using CLSA Business Objects & NHibernate as data access fit really well together). It formalises the concept of a Mobile Object.

1. How many people are using CSLA?
Based on the CSLA Forums, I would say there are quite a number of CSLA based projects out there. Honestly though, I have no idea how many people are actually using it. I have used it in the past on two projects.

2. What are the pros and cons?
While it is difficult to summarise in a short list, here is some of the pro/con's that come to mind.
Pros:

• It's easy to get new developers up to speed. The CSLA book and sample app are great resources to get up to speed.
• The Validation framework is truly world class - and has been "borrowed" for many many other non-CSLA projects and technologies.
• n-Level Undo within your business objects
• Config line change for n-Tier scalability (Note: not even a recompile is necessary)
• Key technologies are abstracted from the "real" code. When WCF was introduced, it had minimal impact on CSLA code.
  
• It is possible to share your business objects between windows and web projects.
• CSLA promotes the normalization of behaviour rather than the normalization of data (leaving the database for data normalization).

Cons:

• Difficulty in unit testing
• Lack of Separation of Concern (generally your business objects have data access code inside them).
• As CSLA promotes the normalization of behavior, rather than the normalization of data, and this can result in business objects that are named similarly, but have different purposes. This can cause some confusion and a feeling like you are not reusing objects appropriately. That said, once the physiological leap is taken, it more than makes sense - it seems inappropriate to structure objects the "old" way.
• It's not "in fashion" to build applications this way. You may struggle to get developers who are passionate about the technology.

3. After reading this does CSLA really not fit in with TDD?
I haven't found an effective way to do TDD with CSLA. That said, I am sure there are many smarter people out there than me that may have tried this with greater success.

4. What are my alternatives?
Domain-Driven-Design is getting big push at the moment (and rightfully so - it's fantastic for some applications). There are also a number of interesting patterns developing from the introduction of LINQ (and LINQ to SQL, Entity Framework, etc). Fowlers book PoEAA, details many patterns that may be suitable for your application. Note that some patterns are competing (i.e. Active Record and Repository), and thus are meant to be used for specific scenarios. While CSLA doesn't exactly match any of the patterns described in that book, it most closely resembles Active Record (although I feel it is short-sighted to claim an exact match for this pattern).

5. If you have stopped using it or decided against why?
I didn't fully recommend CSLA for my last project, because I believe the scope of the application is too large for the benefits CSLA provides.
I would not use CSLA on a web project. I feel there are other technologies better suited to building applications in that environment.

In summary, while CSLA is anything but a silver bullet, it is appropriate for some scenarios.

Hope this helps!

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.

Yes, I (um, we) used it extensively to model our business process logic that was primarily databound forms in a windows forms application. The application was a trading system. CSLA is designed to be at that layer just below the UI.

If you think about your standard complex line-of-business application you may have a form with many fields, many rules for those fields (including cross-field validation rules), you may invoke a modal dialog to edit some child object, you may want to be able to be able to cancel such dialogs and revert back to a previous state. CSLA supports this.

It's cons are that it has a bit of a learning curve.

The key thing to remember is to use CSLA to model how a user interacts with forms on some application. The most efficient way for me was to design the UI and understand it's flows, behaviour and validation rules before building the CSLA objects. Don't have your CSLA objects drive UI design.

We also found it very useful to be able to use CSLA business objects server side to validate objects sent from clients.

We also had built in mechanisms to perform validation asynchronously against web service (i.e. checking the credit limit range of a counterparty against a master).

CSLA enforces a strong seperation between your UI, BusinessLogic and Persistance and we wrote a load of unit tests against them. It may not be strictly TDD because you are driving it from UI design, that doesn't mean it isn't testable.

The only real alternative is creating your own model \ business objects, but pretty soon you end up implementing features that CSLA offers out of the box (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState etc.)

I have used CSLA for one project and it worked great and make things much simpler and neater.

Instead of having your team writing business objects in their own different personal style, we know have a common standard to work against.

//andy

I had experience with it several years ago. It is a brilliant architecture, but very complex, difficult to understand or change, and it's solving a problem that most of us developing web based applications don't necessarily have. It was developed more for windows based applications and handling multi-level undo, with a heavy emphasis on transactional logic. You will probably hear people say that since web applications are request-response at the page level, it is inappropriate, but with AJAX-style web apps maybe this argument doesn't hold so much water.

It has a very deep object model, and it can take a while to really wrap your brain around it. Of course, a lot can change in a few years. I would be interested to hear other recent opinions.

All things considered, it would not be my first choice of architecture.