What is CSLA Framework and Its use? [closed]

Question

What is CSLA Framework and Its use ?

Hadst

Answer 1

CSLA is business object framework that allows you to easily create business objects on top of a data layer. It allows you to architect your application with solid object oriented principals and a good seperation of concerns.

I would highly recommend you read the CSLA book by Rocky Lhotka called Expert C# 2008 Business Objects. That will not only teach you about the framework but also teach good software architecture principals.

You can grab the book here on Amazon

Rockel

Is this a supported framework. And what would be my decision point to use this framework. – Hadst

This is supported by Rocky and it is supported very well. There is a place to report bugs and they are often responded to quickly. – Rockel

easily? can I quote you on that? – Supersensitive

Yes, you can quote me on that. – Rockel

In my experience support for csla is iffy. There are two ppl supporting it, Rocky and Jonny. I have had questions answered immediately. I have questions without replies for months. Take a look at this question #28331392. I asked this same one on the csla site and no response. Most definitely read the suggested reading, the book, so you have a good understanding. The framework has worked for me, very well, but I read the book before I started with it. – Nb

I recently started at a company that uses CSLA - and the first thing I thought (before I started) was that I'd like to get rid of CSLA and get the repository pattern in there. I changed my tune. Turns out, CSLA is a pretty powerful beast and when used correctly - it can enhance the development experience immensely. A type of ORM/Repository pattern - strong on object clean/dirty state facilitation, etc. – Mcneil

"CSLA is business object framework that allows you to easily create business objects on top of a data layer. It allows you to architect your application with solid object oriented principals and a good seperation of concerns."------sooo....what does it do? whats the point using it? – Inna

@PeterPitlock, you can use the repository pattern with CSLA. Requires some thoughtful design but it can be done. – Hadik

Answer 2

My Opinions From My Experience w/ a 1.7M LOC code base:

1. CSLA is intended for a distributed application/database environment. This is why the basic business object is and does everything, for example it's own data persistence. An object (and everything remotely associated w/ its state) is intended to be serialized, sent to a different application and/or data server and work.
2. If the above is not a problem you need to solve, CSLA is overkill, big time. Our development team regrets having committed to CSLA.
3. Juggling all the CSLA balls in a complex Windowed UI is tough. We have multi-tabbed screens (which may in turn open sub-screens) that, unless you follow the "left to right, top to bottom" flow of data entry, and click save often, ends up putting and/or fetching incomplete data to/from the database; or dropping data altogether that you just entered. Yes, our original coders are at fault, but so is CSLA... It just seems that there are so many moving parts to enable, control, and coordinate CSLA features. It's like having to deal with all the dials & switches of a fighter jet when all you really need is something more like a Cessna 152.
4. You will write lots of custom code to enable the CSLA features. For example CSLA will never be confused with object relational mapper (ORM) tools like Hibernate and Entity Framework. Our SAVE() methods are non trivial, so are the trivial ones.
5. Encouraging the use of code generators compounds problems. We used CodeSMith to generate classes from data tables. So we end up with code that has a 1-1 correspondence of table to c# class. So you must write all the code to handle dataStore to your "real" objects.
6. Data store/ and fetch is very inefficient w/ CSLA. Because of the Behemoth, monolithic BusinessObject-does-all-and-knows-all centric paradigm, objects end up doing a one-object-at-a-time data fetch and instantiate. Collections of composite objects significantly compound the problem. A single "get this object" always results in a cascade of separate data fetches (one or more for each individual object) to instantiate the entire inheritance & composite relationship chains. Its known as the "N+1 query problem." Oh, and fetching data ALWAYS results in a new object being created, even if we're only updating an existing one. No wonder our more complex screens are FUBAR.

It allows you to architect your application with solid object oriented principals and a good seperation of concerns.

Yes and no. Mostly no.

The BusinessObject handles it's own data storing. That is anti separation of concerns.

"It allows you..." well, yeah - so does a blank text editor screen, but does not force or encourage you like the MVC.NET framework does, for example. IMHO, CLSA provides absolutely zero benefit for ensuring that the code you develop with it follows "solid OO principles". In fact coders w/ weak OO skills (the majority, in my experience) will really stand out when using CSLA! Woe betide the maintenance programmer.

CSLA is the poster child for the solid object oriented principle favor composition over inheritance. CLSA code is untestable. Because an inherited framework BusinessObject is, does, and needs everything, all at once and every time, it's not likely that you will be able to get much test coverage. You can't get at the pieces because everything is tightly coupled.The framework is not amenable to dependency injection. It is an iron curtain of code.

Your code will be difficult to debug. Call stacks get very deep and as you get near the center of the sun so to speak, everything turns into reflection - "what *&^# methods just got called???" And you simply get lost. period.

EDIT 7 Mar 2016

What more insight can I add after the original post? Two things, perhaps:

First, It feels like CSLA has some promise. If we knew how to juggle all those moving parts together. But CSLA is so enigmatic that even things we have done right are corrupted over time. IMHO without a very strong team-wide CSLA wherewithal, any implementation is doomed. Without a vibrant "open source" of technical references, training, and community it's hopeless. In almost a decade our CSLA code, in my final analysis, is just compounding technical debt.

Second, here is a recent comment I made, below:

Our complexity often does not seem to fit in the CSLA infrastructure so we write outside of the framework. This and cheap labor results in rampant SRP violations and has me hitting brick walls managing dynamic rule application, for example. Then, CSLA parent/child infrastructure propagates composite object validation but we don't always want c/p relationships, so we write more validation and store code. So today our CSLA implementation is inconsistent & confusing. Refactoring to more-better CSLA will have profound domino effects. So after that initial injection CSLA is essentially abandoned.

end Edit

Dewclaw

I wish I could up-vote this 1000 times. CSLA is by far the worst framework I've ever had the displeasure of working with. It would probably work well for trivial distributed programs. But like you said, serious work requires tools that expose power, not limit you. The whole BusinessObject<T> thing is really the worst. It forces every BO class you have to inherit that single abstract object. And the way it does it (via generics) totally screws with your ability to inherit business objects. It really is a horrible framework. – Voncile

Just for other people looking at this question/answer, it seems to me that allot of your frustration is due to the fact that you're application was trying to persist the actual business object in the database which in my opinion you shouldn't do and is actually discouraged by CSLA. If you would have separated your concerns properly and do persistence in a separate layer (factories/repositories were you would map the business object to a data layer entity and vice-versa) you would have had a much easier life. – Falster

I completely agree with Cristian. If your business objects are constructed in a way which requires individual root objects referenced by other root objects, you are doing things inappropriately. I have had very large trees of objects get loaded from a single query against the database, returning multiple result sets. A stock codegen tool would work poorly. In our case I created a DSL which allowed us to generate our business objects from multiple tables or stored procs, along with specifying what type of object it was and the permissions on it. That sped up development by about 300%. – Cos

If you're generated your BOs from your database schema, you're doing Csla wrong. Rocky has flat out said if you do this with Csla you will fail unless your app is trivial. Csla is also testable, I've done this with quite a few apps at this point. The biggest benefit I've seen with Csla is the business rule support, which with 4 and higher is very testable, not the mobile objects. Your problems are 100% due to your object design, not Csla. Remove Csla but keep your Bo structure based on your tables, and you'll have many of the same issues. – Theo

-1 Imagine this: you are starting to think/design a new system. If your design is still in its infancy and you're already thinking of tables/foreignKeys/fetching/storing, I wouldn't recommend to use CSLA since you are not building an object oriented system. – Neal

@daniloquio, ... What? If you mean CSLA is very OO I agree. If you're implying our implementation is not OO by intent you are very mistaken. Now there's plenty to criticize in our code but CSLA is complex and abstruse causing "mishandling" - that's CSLA's fault. – Dewclaw

My comment isn't completely related to the implementation you did. I was thinking on the awful lot of people how could benefit from CSLA big time but won't because this super-popular SO answer will scare them out. I guess I just wish I could down-vote this 10 times, but I can't; hence my comment. Conclusion, I'm not bashing out on your implementation, I'm bashing out on a very common development approach that is not compatible with CSLA. My people will understand me and they will be less influenced by this over hyped answer. – Neal

Our complexity often does not seem to fit in the CSLA infrastructure so we write outside of the framework. This and cheap labor results in rampant SRP violations and has me hitting brick walls managing dynamic rule application, for example. Then, CSLA parent/child infrastructure propagates composite object validation but we don't always want c/p relationships, so we write more validation and store code. So today our CSLA implementation is inconsistent & confusing. Refactoring to more-better CSLA will have profound domino effects. So after that initial injection CSLA is essentially abandoned. – Dewclaw

Down voted: It looks like your poor knowledge of CSLA (and maybe OOP in general) is shaping your reply. If you built BusinessObject-does-all-and-knows-all objects, it's your fault, not CSLA's. You can also create small objects with clearly defined responsibilities. The framework is not going to force you in one direction or the other. – Cleome

How CSLA plays in our system's saga is more telling than degrees of OOPness. CSLA became a technical debt generator for 2 reasons - its complexity + lack of resources. Then, us. Take a fantastic foundational design, after a couple of releases introduce CSLA. Our initial CSLA core is well written and OOPy as all git-out. Cum reality: team churn, tight schedules, putting out fires, etc. My biggest practical lesson: I could find anything about .NET and nothing about CSLA. One lousy book. Who would be using .NET today given a similar level of open source support? – Dewclaw

Answer 3

I suggest reading the What is CSLA? page, and browse through the CSLA .NET FAQ site.

For the latest published information check out the Using CSLA 4 ebook series.

Eichhorn

CSLA .NET moved to GitHub a couple years ago - the home page is now cslanet.com – Eichhorn

Answer 4

In reply to @radarbob https://mcmap.net/q/523053/-what-is-csla-framework-and-its-use-closed, hope I won't regret this and start a flame war.

Our team has been developing a couple of LOB applications with CSLA. From my experience on writing green field apps with CSLA and maintaining existing code here are my replies to your points.

1. The BO is not suppose to do it's own data persistence, you will have a Factory that will handle all data persistance, for example using a ORM to map to Models that are later on saved.

2. Sorry to hear that, I make sure I study the framework documentation and write at least one toy application before committing to a existing code database. Furthermore you can even download and browse the CSLA code.

3. You have BO -> Portal -> Factories that should not be very complicated the existing CSLA examples go a long way on explaining what is happening on each level.

4. CLSA should never be confused with a ORM

5. As you should, business object are rarely mapped to one table and thus require a bit of work when saving. In the case they are mapped to one table to you use something like AutoMapper to map your BO to your POCO in 1 line.

6. Look into CSLA Commands, also is nothing stopping you from keeping your BO as small or big as you want as long as you keep in mind that they are not the same as the POCO's that you will persist.

In a project we worked on we where able to easily test BO to ensure that the business logic was correct. Because of the nice separation of concerns we tested our Factories in isolation to make sure that business objects will be persisted accordingly.

At one point I was able to easily persist part of my BO's in MongoDB so the application was running on a hybrid database MSSQL and MongoDB without having to even change one line of code in my business objects, all I had to do was to update the factories to use Mongo instead of the current ORM.

Hope this addresses all your points in a fair manner,

Regards

Jd

Answer 5

CSLA: Component-based Scalable Logical Architecture

A paragraph in a nutshell that described CSLA to me from the website was this:

CSLA .NET enables you to create an object-oriented business layer that abstracts and encapsulates your business logic and data. The framework ensures your business objects work seamlessly with all .NET interface technologies, including WinRT XAML, WPF, ASP.NET MVC, ASP.NET Web Forms, WCF, asmx services, Windows Phone 7, Silverlight, Windows Workflow and Windows Forms.

Why you might use it:

Business rule management. Once you learn the business rule system, it provides a way to enforce business logic in a tidy package. If you have an object with child objects that need to report Validation to the parent most level, there is a way to handle that. (see http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx for more information on the rule system)

You have business objects that you need to support N-level undo? A CSLA BusinessBase has a baked in property management system (like dependency properties) for functionality like N-Level Undo (it is actually completely implemented.) (This also ties into the business rule management. You can fire validation when a primary property changes, or you can change a property based on the value of another property.)

Data portal management. This one was an interesting concept. If I need to execute data operations locally, CSLA is configured for this out of the box. I can also stand up a WCF service that references my business object libraries, and use a few lines of configuration to make a WCF endpoint to manage data operations. The WCF service is a part of the CSLA framework. It was neat to see this in action. Other scenarios? Sure! Your business object library doesn't need to change, the DataPortal class determines if it needs to execute remotely or locally, according to your configuration.

CSLA does force you to use a few mechanisms that may not feel natural at first. I think that is somewhat true of any pattern you choose to implement. However, when it comes to the challenges of implementing Service Oriented Architecture, CSLA offers a lot. Yes, you are going to have an architect level developer authoring some of your libraries. However, if you're building an enterprise class application, shouldn't you be doing that already?

CSLA, when architected correctly, is testable. We use the repository pattern to replace out the actual dal with a mock layer and test both by specification (using NUnit/SpecFlow) and in a unit fashion when appropriate.

As far as support, including Rocky himself, there is a community of contributors that ensure things like CSLA.Net for Xamarin become a reality. There are consultancies that know CSLA and use it on a regular basis depending on the scope of work (and no, not just the consultancy for which I work.)

All things considered, CSLA may not be for you. Like others have indicated, read the site and the books (especially Expert C# 2008 Business Objects.) Ask questions, as the CSLA community tends to give quality advice.

Earache

Almost felt bad for changing your score from an OCD friendly 999 (at voting time) to that ugly ass 1009. – Neal

Answer 6

CSLA is described in detail here. The new book is a great starting point. As a great compliment to the book I would recommend checking out our CSLA 3.8 templates. Rocky recommends using a Code Generator, and we have the leading set of templates, that will get you up and running in no time.

Thanks -Blake Niemyjski (Author of the CodeSmith CSLA Templates)

Cockatoo