CSLA Not Being Used? Any Commercial Examples?

CSLA Not Being Used? Any Commercial Examples?

Old forum URL: forums.lhotka.net/forums/t/12398.aspx


MackPoone posted on Wednesday, February 26, 2014

We were about to start a mid-sized project that included several different user interfaces( WPF, WebForms, Windows Phone 8, etc) and was trying to find some resources that had CSLA experience.   We were told by many individuals that we contacted that this technology was no longer used but by a very few organizations/companies and they suggested we go with a different approach.  They then backed this up by doing some searches and was unable to find a lot of example of people using the (current) framework.

I was just wondering if there are any lists of commercially apps that are using the current versions of CSLA framework (4.0 +)? 

To be fair I researched it for a short period of time and had trouble finding examples.   I seemed to wade through lots of old posts and it didn't appear that there were a lot of current talk about the framework.  I was just wondering if the framework popularity was losing traction?

To be fair I did find one rather large software company in the Hospice industry called Suncoast that had used CSLA.NET pretty successfully.

I just don't want to go down the path of trying to find resources only to find out this technology has taken a backseat and will be costly to implement and maintain.

Thanks for any insight.

skagen00 replied on Thursday, February 27, 2014

We have a hosted solution using CSLA using Silverlight (and soon leveraging PhoneGap or Icenium on top of our CSLA business layer to deliver iOS & Android support - not in full capacity but a start).

I think that if my solution were straight Web and always would be, I am not positive that there are extreme merits for using CSLA other than familiarity and development consistency.  However, one thing that I gained by leveraging CSLA was that when it was clear we needed additional UI's beyond Silverlight, the investment was heavily protected by having leveraged CSLA and adhering to OOP principles which CSLA helps to support.

Our CSLA application services 300+ clients at present, and is very much a commercial application.  I have no qualms at any point defending the use of CSLA within our application.

All of that said, I do believe CSLA is at a certain juncture that is different than what it has ever faced.  The fragmentation of the client has created a situation where the absolute joys of working with CSLA are mitigated; the business objects can't nicely flow from client to server and always provide the true richness with ease that they once could.  If one sees the three main players going forward (natively) as iOS, Android, and WinRT - one of them simply doesn't work (iOS) and the other requires dependency on Xamarin (for Android, which I have not worked with), and the final option has serious issues which Rocky has blogged about.

While CSLA's bread and butter is the business layer, it's adoption requires application.  It requires being able to take that business layer and expose it to clients through interfaces.  Silverlight was a fantastic route -- truly, what a perfect technology for CSLA; Rocky had one blog post that more or less stated that Silverlight represented the future of development for most of us - I believe this occurred right around the time of the iPad introduction; my how things have changed.

I guess the bottom line I would say is that CSLA is not some closed application framework like a few other technology/frameworks we looked at when we chose CSLA.   We had training materials in the book (and later the videos, but everything certainly is getting a little dated).   We have been able to leverage the framework with absolute minimal changes (indexer support on PropertyStatus for one).  Developers come in and there is consistency through our business layer as CSLA generally has a designated place for "a way to do something".   One other aspect that tilted us was the forums and community support.  To be fair, it feels less busy than it once did.

In the end, CSLA is just code.  If you feel comfortable going with .NET, I will say that CSLA provides a great OOP orientated set of code to build upon. 

I just wanted to chime in and say, yes, it's being used.  Rocky had a list at one point of all the places CSLA was being used.  Ours isn't mentioned as I don't believe I'd really be at liberty.

RockfordLhotka replied on Wednesday, March 05, 2014

https://github.com/MarimerLLC/csla/wiki/Testimonials-and-Usage

ajj3085 replied on Wednesday, March 05, 2014

skagen00
All of that said, I do believe CSLA is at a certain juncture that is different than what it has ever faced.  The fragmentation of the client has created a situation where the absolute joys of working with CSLA are mitigated; the business objects can't nicely flow from client to server and always provide the true richness with ease that they once could.  If one sees the three main players going forward (natively) as iOS, Android, and WinRT - one of them simply doesn't work (iOS) and the other requires dependency on Xamarin (for Android, which I have not worked with), and the final option has serious issues which Rocky has blogged about

I have to say I disagree with this.  Even with just a web site or service Csla provides compelling features.  The biggest is the rules engine which is extremely powerful and still doesn't have a good framework to replace it.   Also the consistency it helps provide is a great aid to maintainability and the nature of the framework really lends itself to well designed classes. 

skagen00 replied on Thursday, March 06, 2014

Ugh, I had a really long post typed out for this, and my network connection was lost and I lost my reply - so I'll be more brief -

I never suggested CSLA doesn't provide compelling features.  Totally agree and I will be using CSLA for as long as I'm in my current engagement - likely many more years.

What I do believe though is that one of the advantages of CSLA, as you well know, is the concept of mobile objects.  CSLA has no real benefit _in this area_ when looking at iOS or Web applications.  For some software projects that may not be a big deal, but for ours, a very rich LOB application that needs reach, it's a big deal.

All I was referring to is the notion that CSLA's best trait, in my opinion, is getting diminished - that being the concept of mobile objects.  You don't get it with HTML/JS and you don't get it via iOS.

I haven't used CSLA in VB6, I did some WebForms, I touched MVC, but the vast majority has been in Silverlight - when using Silverlight, it's like someone envisioned the perfect complement for CSLA (or vice versa).  My colleague, when just casually chatting about the technology landscape, said "I don't know of a web site that does 20% of what we do".  Hyperbole, but just the richness mobile objects offers is hard to over-estimate.

Other frameworks may have had that to some degree - CSLA just has it, period.

That's all I was saying.  And unless I misjudged some blog posts over the past year, the thought of "how can we make web development with CSLA more like CSLA" has definitely been on the mind of the blogger.

 

ajj3085 replied on Thursday, March 06, 2014

skagen00
....snip....

Yes, I can see your point there.  The loss of state does make life harder and its something I've been dealing with as I try to get Csla adopted for the server side of web services.  So I'm trying to tout the other features, especially the rules engine as this is an area we struggle with.

cfarren replied on Thursday, February 27, 2014

Sybiz Software is an Australian based software house that develop Accounting, HRM and payroll as well as a CRM solution and these all use CSLA. Unfortunately we aren't able to upgrade our latest software to CSLA 4.x because it would just take too long to migrate across. However, our future software will be using CSLA 4.x mainly (but not solely) because of the rules engine. CSLA has, in our opinion, the simplest and most versatile rules engine around and when you have software with thousands of rules, that is important.

Copyright (c) Marimer LLC