Why should we commit to CSLA? Is there long-term future?
BlagoCuljak opened this issue · comments
Hi guys,
In the last couple of weeks, we are having a major discussion about should we commit to CSLA, do we benefit from it, is there any value to know the CSLA framework as a dev, is the project too dependent on @rockfordlhotka?
Senior developers have some good arguments about CSLA, it's followed closely Asp core technologies and upgrades, it forces us to have a scalable architecture, separation of concerns, and we get to work with whatever UI we want.
Some younger devs, who come from MVC/Javascript/Full Stack world, says that CSLA is just too complex, the last Stackoverflow question was in 2016, and some questions about CSLA on SO, are not in CSLA favor, the project doesn't have the critical mass to sustain without Rocky, and there's too much code involved.
Given all of these questions and if you are some architect of Enterprise applications, is there any validity in previous statements?
Hope that we can have an honest discussion.
Version and Platform
CSLA version: 5.1
@BlagoCuljak ,
I have used Csla since 1.XX version, here are my thoughts and observations
-
As your younger devs say Csla is 'complex'. Yes it is complex in the way that it's an OO framework and OO programming is not for the faint of heart.
-
Csla does use 'advanced' features of .NET framework.
-
Your senior devs should be able to get junior devs started on Csla (my opinion).
-
I have noticed that if your team has members who don't want to update their skills, it's problem that will manifest itself in the future, whether or not Csla is involved.
-
Csla is, if I may quote @rockfordlhotka , Rocky's labor of love so it is dependent upon Rocky but the code is open source and we have some great folks (in addition to Rocky of course) like @JasonBock , @jonnybee and many others who would gladly help you.
-
Benefits of Csla are just too many in our case
a) The ability to reuse your code in different UIs (like you mentioned).
b) great business rules engine, my team mates were surprised when I used 'ruleset' in Csla.
c) My business objects needed to access a 'legacy' database (readonly) and 'new' database
for everything else and it was a breeze with Csla.
d) Csla gives your code a 'defined' structure.
e) Could you imagine your own custom objects implementing all the interfaces that Csla base
classes already implement?
f) Again Business rules engine, as our rules are objects, we can resuse them easily and we have
done that in our projects a lot.
e) Authorization rules helped us tremendously. -
We are looking forward to using Csla and Blazor and hopefully reduce our dependency on javascript. Personally I am hoping to eliminate writing javascript code in the near future :)
Regards
tl;dr - I think there's validity to CSLA having become less relevant as the industry (was forced to?) took a path leading to some really horrific architectural choices. However, with the rebirth of the smart client via WebAssembly/Blazor (in particular), all the amazing power and capabilities of CSLA come back into play.
The timing of the SO comments are pretty funny, as in another thread we were just discussing how SO is pretty crappy in so many ways 😄
To be fair, beyond SO being a toxic cesspool, the practices around structured enterprise software changed a lot as the smart client world basically faded into the background, replaced by mainframe-style web development.
Then the smart client world started to come back, but with the client being written in JavaScript/TypeScript/Angular/React, forcing everyone to duplicate all their business logic on client and server (or in real life just write it on the client and ignore the negative ramifications). As an industry we adopted the one of the most expensive, fragile, and hard to maintain software architecture available.
I rather thought nodejs was the way out - at least get us back to where a single set of business logic could be directly run on client and server. And although node made some inroads, it hasn't displaced Java or .NET by a long shot.
And, of course, a whole lot of "full stack" web software is really just server-side code in MVC or whatever: just like the mainframe/minicomputer world from 1990. Which is fine as far as it goes, but personally I find that world pretty boring, given that is where I started my career 😄
Don't get me wrong, server-side web pages and services all need business logic, and CSLA provides a home for business logic - so parts of CSLA (the rules engine, etc.) remain extremely valuable for both full stack and modern web development. This can include the data portal in the case that your enterprise app can't all run on a web server, but also needs app servers. Especially if they are hosted in container orchestrators like Kubernetes.
A lot of great features were added to CSLA around the 4.9 to 4.11 timeframe around Kubernetes and container orchestration support.
Now we're on the cusp (imo) of a wonderful rebirth of smart client development thanks to WebAssembly. The concept of having some type of browser-hosted assembly language is something I've advocated since around 1999.
In the 1999-2001 timeframe, before the dot-bomb, the industry was having really meaningful discussions around whether the browser should be a colorful terminal or a real runtime for code. The dot-bomb sidetracked that discussion; really derailed it for many, many years. The DHTML and then HTML5 evolution, over so very many years, ultimately demonstrated that the browser can be, and probably should be, the singular client-side runtime for most apps. Angular, React, Knockout, Vue, etc. all demonstrate this, as does Slack, Teams, gmail, outlook.com, the Azure Portal, and many other rich smart-client apps that are browser-hosted.
Thanks to Mozilla (and others) we now have the ability to escape the JavaScript hegemony, and run nearly any language natively in the browser - on any device, on any OS. Thanks to the open source mono project we have .NET running on wasm in all those browsers. Thanks to the ASP.NET team we have the Blazor UI framework running on mono (and Uno, Ooui, and other UI frameworks too).
The end result is that all the amazing features of CSLA are now available to "web developers" via Blazor.
I put "web developers" in quotes, because it is true that web developers are attracted to Blazor for many reasons. But so are traditional smart client developers from the Windows Forms, WPF, iOS, Android, GTK+, and other worlds. Blazor is a smart client UI framework that happens to run in browsers - so it appeals to web developers and smart client developers equally.
CSLA 5 supports Blazor, and that support continues to evolve and improve (along with Blazor itself). And it brings all the existing support for container-based server environments, plus the rules engine and all the other happiness provided by CSLA over the years.
You can probably sense my excitement!
For a few years now I've anticipated that the future runtime for most enterprise apps is WebAssembly clients talking to container-based (Linux-hosted) services. CSLA makes that environment truly sing!
My 2c here. I've personally been using Csla since the VB5 days and at our company we've been using Csla since 2002.
In the VB5 days Csla was really just a way to write code, not really any components to use that I can recall. ADO recordsets was a real problem back then. Before Csla most devs (me included) co-mingled database access code in the UI becuase it was just too easy. The problem was that every time MS came out with a new version of their ADO component you had to rewrite most of your code. Fortunately I stumbled upon Rocky's book one day and it changed me. After converting to Csla, ADO was centralized in the data tier and it took me no time to keep up with breaking changes.
Since then, we've stayed up with Rocky's framework, and it has paid off over the years. Our code that runs [Transactional] still works, and our new code uses EF. No problems. We're going to be switching UI's from Winforms to Xamarin and won't have to rewrite our entire code-base. Rocky and his team have been staying on top of the changing technology. Our code is still the same.
The debate you're having is a tough one. No one wants to make the wrong choice, but they need to make a choice, and we love data! But you need someone that really knows Csla in order to do a comparison.
If you have the luxury of doing this, create a prototype and have two teams create it. One Csla and the other, whatever they want. We actually did this. I really needed to do this because I was wondering if I was old-school while all of these new technologies are just coming out like crazy. So I tasked a team to 'be like a startup'. I wanted to question the very core of what we do using Csla over the decades, just to make sure my thinking is still good. They researched all of the latest, used all of the popular platforms, and went at it. Not too long in, problems started to occur. Nothing big that they couldn't solve, but we then started running into barriers with (what I thought are) simple things. I can't recall a specific issue, something with binary serialization over the web with a file attachment? (which is an Attachment object for us with a binary stream property)... They had no clear way to have a rules system without a lot of work. There was no system in place to have centralized logic. Sometimes someone would save an object and it wouldn't work. Authorization and login was so far out of the picture that it wasn't even thought about. I asked about having some sort of API (which we use our Csla library for) and it was going to be a huge task. Eventually all of the problems they ran into were solved with a "let me show you how I'd do this in Csla". We had (and still have) some learning curves ourselves on how our our Csla Business objects fit within the MVVM world, but once we got over that, the productivity gains and code re-use is amazing.
Good luck!
My 0.02$:
is the project too dependent on @rockfordlhotka?
Yes...but a lot of OSS projects have this dependency. Unless there is corporate backing (like Microsoft with .NET), it's at some point being supported by one person or a handful of people (which also means OSS projects need some love from people to help with fixing bugs, adding features, etc.)
Some younger devs, who come from MVC/Javascript/Full Stack world, says that CSLA is just too complex, the last Stackoverflow question was in 2016, and some questions about CSLA on SO, are not in CSLA favor, the project doesn't have the critical mass to sustain without Rocky, and there's too much code involved.
To some degree, this is fair. I've always had a love/....not-love relationship with CSLA (I consider
@rockfordlhotka as a friend and he's also sort-of my boss and I don't hesitate to say that :) ). There are things about it that I like, and there are some that I wasn't fond of. Over time Rocky's been able to address some of them (especially around DI/IoC and serialization improvements). Also, with the rise of JS-based clients, that took away one big place that CSLA really worked well for me. But with Blazor and other UI technologies .NET-based, this aspect is definitely coming back.
I've used CSLA off an on for 12 years on projects (and FWIW I'm also the primary developer for the CSLA analyzers). I'm sure if I looked back on some of that code, I'd cringe a bit. But, overall it served itself well, and I think there's even more room to grow and improve CSLA in 2020 and beyond.
One other thing. Even if you don't "commit" to CSLA, the principle of keeping your domain logic, validation, etc. out of your persistence and UI layers is a good principle to follow, no matter what architecture, language, runtime you use.
@JasonBock , almost 10/12 years we did use another framework (coincidentally developed by Rocky's friend from CA) and although it was a very good framework it couldn't keep up with the latest UIs back then (like WPF, that was 2008-- 2010 :) ).
We noticed that Csla was keeping up with the latest and greatest : ) and we decided to stick with it.
I am curious, you mentioned you have used Csla on and off, what other options did you use/consider?
Kind regards
@Chicagoan2016 there really aren't any other options that I've seen. That doesn't mean there they don't exist, I just haven't found them.
When I say "on and off" I've been on projects that didn't use CSLA to start and introducing it at that point is counterproductive. Some projects I'm on, there isn't a good point to having CSLA in play.
fwiw, I blogged What happens to CSLA .NET support if Rocky is hit by a bus? back in 2016.
The "core leadership team" has evolved over time, and will continue to evolve I'm sure - that's the nature of this sort of project. The number of contributors has increased since 2016, which is good given how .NET has expanded to embrace Linux, containers, WebAssembly, and so much more!
@rockfordlhotka that link doesn't work.
Fixed - copy-paste error...
@rockfordlhotka , we don't hear from Kevin Ford or does he use an alias here? :)
Kevin does use an alias (@Bowman74 ), and he's been focusing on machine learning for a while now - a space where CSLA doesn't fit.
Hope we don't lose Kevin to the machine learning world, it will be a sad day for the Csla community :)