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

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 wanted to use it, but my then lead developer had the idea too much 'magic' was involved...

Answer 3

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 4

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)

Answer 5

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 6

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!