Does anyone have any real-world experience of CSLA?

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?

In defence of the CSLA, although I do agree with many of the comments that have been made particularly the unit testing one...

My company used it extensively for a Windows Forms data entry application, with a high degree of success.

- It provided out of the box functionality that we didn't have the time or expertise to write ourselves.
- It standardised all of our business objects making maintenance easy and reducing the learning curve for our new developers.

On the whole I would say that any issues that it caused were more than outwayed by the benefits.

UPDATE: Further to this we are still using it for our windows forms app but experiments with using it for other applications such as web sites have shown that it is perhaps to cumbersome when you don't need much of its functionality and we are now investigating lighter weight options for these scenarios.

Not to take CSLA of the list, but before using it, research the benefits and make sure they really apply. Will your team be able to correctly/consistently implement it? Remoting and portal dance needed?

I think beyond all the theoretical ponder, it is all about clean/maintainable/extendable/testable code following basic proven patterns.

I counted lines of code needed in a specific domain of a project converted from CSLA. Between all the different CSLA objects(readonly+editable+root+list combinations) and their stored procs it took about 1700 lines, versus a Linq2SQL + Repository implementation that took 180 lines. The Linq2SQL version consisted mostly of generated classes that your team doesn’t need to consume book to understand. And yes, I used CodeSmith to generate the CSLA parts, but I now believe in DRY code with single responsibility bits, and the CSLA implementation now looks to me like yesterday’s hero.

As an alternative I would like to suggest looking into Linq2Sql/Entity Framework/NHibernate combined with Repository and UnitOfWork patterns. Have a look at

[To see links please register here]

Cheers!

John,

We have teams working in CSLA from 2 to 3.5 and have found it a great way to provide a consistant framework so all the developers are "doing it the same way". It is great that most of the low value code is generated and we know when we run unit tests they work out of the box for all the CRUD stuff. We find that our TDD really comes in with the refactoring we do to design, and CSLA doesn't prevent us from doing any of that.

Chris

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.

I am using CSLA as the business object framework for a medium size project. The framework has come a long way from the VB6 days and offers an extraordinary amount of flexibility and "out of the box" functionality. CSLA's mobile smart objects makes UI development much easier. However, I agree with others it isn't the right tool for every situation. There is definitely some overhead involved, but also a lot of power. Personally, I am looking forward to using the CSLA Light with Silverlight.

<h2>Pros:</h2>
<ul>
<li>Data technology agnostic<sup>1</sup></li>
<li>Large install base and it's FREE!!</li>
<li>Stable and Logical framework</li>
<li>Data Access code can be in your objects or in a separate assembly</li>
<li>Property and Object Validation and Authorization</li>
</ul>
<h2>Cons</h2>
<ul>
<li>The code can be a lot to maintain<sup>2</sup></li>
<li>Probably need a code generator to use effectively
<li>Learning curve. The structure of CSLA objects are easy to grasp, but the caveats can create headaches.

</ul><br />
I'm not sure about test driven design. I don't unit test or test driven design (shame on me), so I don't know if unit tests are different than TDD, but I know that the most recent version of the framework comes with unit tests.

<br />
<sup>1</sup> Good thing because data access technologies never stay the same for long.<br />
<sup>2</sup> This has gotten better with recent versions of the framework.

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](

[To see links please register here]

), 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.

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][1] being the best approach


[1]:

[To see links please register here]

Our company practised CSLA in some of its projects and some of the legacy projects remain to be CSLA. Other projects moved away from it because CSLA violated a plain and simple OOP rule: Single Responsibility Principle.

CSLA objects are self-sustaining, e.g. they retrieve their own data, they manage their own behavior, they save themselves. Unfortunately this meant that your average CSLA object has at least three responsibilities -- representing the domain model, containing business rules, and containing data access definition (not the DAL, or data access implementation, as I previously stated/implied) all at the same time.

CSLA is the best application framework that exists. Rocky LHotka is a very but very smart guy. He is writing the history of software development like Martin Fowler, David S Platt, but my favourites writers are Rod Stephens, Mathew mcDonalds Jeff Levinson thearon willis and Louis Davidson alias dr sql. :-)
Pros: All design patterns are applied.
Cons: Hard to learn, and few samples.