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

I used it for a project a couple years ago. But when the project was done, I couldn't tell anyone what CSLA did for me. Sure, I inherited from its classes. But I was able to remove that inheritance from almost all classes with no restructuring. We had no use for the N-Tier stuff. The n-level undo was so slow that we couldn't use it. So I guess at the end it only helped us model our classes.

Having said that, other teams have started using it (after a horrid attempt by a team to create their own framework). So there has to be something worthwhile in there, because they're all smarter than me!

Answer 2

We've been using CSLA now for over five years, and we think it works great for constructing business applications. Coupled with code generation you can create business objects in a relative short amount of time and focus your effort on the meat of the application.

Answer 3

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

Answer 4

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

Answer 5

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.

Pros:

• Data technology agnostic¹
• Large install base and it's FREE!!
• Stable and Logical framework
• Data Access code can be in your objects or in a separate assembly
• Property and Object Validation and Authorization

Cons

• The code can be a lot to maintain²
• Probably need a code generator to use effectively
• Learning curve. The structure of CSLA objects are easy to grasp, but the caveats can create headaches.

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.

¹ Good thing because data access technologies never stay the same for long.
² This has gotten better with recent versions of the framework.

Answer 6

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