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

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.

Answer 2

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 3

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

Answer 4

I wanted to use it, but my then lead developer had the idea too much 'magic' was involved...

Answer 5

I've been using CSLA since vb5, when it was more of a collection of patterns than it was a framework. With the introduction of.NET, CSLA turned into a full-blown framework, that came with a hefty learning curve. However, the CSLA addresses many things that all business developers tend to write themselves at some point (depending on project scope): validation logic, authentication logic, undo functionality, dirty logic, etc. All of these things you get for free out of the box in one nice framework.

As others have stated, being a framework, it forces developers to write business logic in a similar fashion. It also forces you to provide a level of abstraction for your business logic, so that not using a UI framework such as MVC, MVP, MVVM becomes not so important.

In fact, I would argue that the reason why so many of these UI patterns are so hyped up today (in the Microsoft world) is that people have been doing stuff incredibly wrong for so long (ie., using DataGrids in your UI, sprinkling your business logic everywhere. tisk tisk). Design your middle tier (business logic) correctly from the start, you can reuse your middle tier in ANY UI. Win Form, ASP.NET/MVC, WCF Service, WPF, Silverlight**, Windows Service, ....

But aside from these, the huge payoff for me has been it's built-in ability to scale. The CSLA uses a proxy pattern that is configurable via your config file. This allows your business objects to make remote calls from server to server, without having to write one lick of code. Adding more users to your system? No problem, deploy your CSLA business objects to a new application server, make a config file entry change, and BAM!! Instant scalability needs met.

Compare this to using DTO's, storing your business logic on the client (whatever client that may be), and having to write each of your own CRUD methods as service methods. YIKES!!! Not saying this is a bad approach, but I wouldn't want to do it. Not when there's a framework out there to essentially do it for me.

I'm going to reiterate what other folks have said in that CSLA is NOT an ORM. CSLA forces you to supply your business objects with data. They do not care where you get your data. You can use an ORM to supply your business objects with data. You can also use raw ADO.NET, other services (RESTFUl, SOAP), excel spreadsheets, I can keep going here.

As for your support for TDD, I have never tried using that approach with CSLA either. I have taken the approach where I model my middle tier (ala business objects) using class and sequence diagrams, most often allowing use case, screen and/or process design to dictate. Perhaps a bit old school, but UML has always served me very well in my design and development efforts. I've successfully designed and developed very large and scalable applications still being used today. And until WCF RIA matures, I'll be continuing to use CSLA..

** with some work arounds

Answer 6

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 http://www.codeplex.com/backgroundmotion

Cheers!