How HTML5 destroyed my CSLA dream
Update 10/2016 - This posting is better viewed in my new blog.
Let me start by stating, emphatically: I LOVE CSLA .NET!
I first became aware of this excellent framework in 2008 when my boss dropped Rocky's book Expert C# 2008 Business Objects on my desk. In very short order I recognized the enormous benefits CSLA could provide to developers like myself who where trying to to produce great enterprise applications. The idea that I could create completely self-contained classes which would flow naturally between the various application layers and physical tiers made me fairly giddy with excitement. This excitement was reinforced by my efforts as I implemented user presentation layers for WinForms, WPF and Silverlight all based on the same business core with little impedance between the architectural layers or the physical tiers. Concerns such as validation and n-level undo were mostly handled by the CSLA framework with very little additional effort from the developer (me).
Then I attempted to write a presentation layer in HTML 5.
I started with ASP.NET MVC 4 because that framework is supported by CSLA and there are a variety of sample applications employing the two frameworks in tandem. I quickly found that, while you can develop an MVC application utilizing a CSLA based business core, it's almost impossible to take advantage of any of the benefits offered by CSLA from the client (i.e. browser). In the other UI technologies I'd previously implemented, object binding allowed for a vibrant user experience where, for example, clients could easily be notified when they'd made changes to an object or the object was not in a valid state. Due to the stateless nature of the MVC implementation such notification was simply impossible to leverage. Unfortunately, today's users expect exactly this type of client-side responsiveness in their applications.
I've continued building my HTML 5 application and over time I've slowly added more and more client-side "bells and whistles" all, of course, written in Javascript. What I've found is that I've functionally re-coded a large number of the business and functional rules once encapsulated solely in my CSLA business objects into client-side Javascript. I now maintain a significant number of these rules in two different code bases (and languages). My original CSLA based business objects are still the workhorses for the application when a users works with one of Microsoft's presentation technologies and they back all server-side activity but they provide very few meaningful functions when accessed through a web UI. This makes me very sad.
I had a dream of one unified code base providing a consistent experience across a variety of platforms. Over the last year and a half I've watched the HTML5/Javascript/CSS juggernaut roll onto the scene and relegate all other contenders for development of multi-platform capable applications to the fringe.
In quieter moments I can still hear the death cries of my CSLA dream. Rest in peace buddy. You were awe inspiring while you lasted.
Let me start by stating, emphatically: I LOVE CSLA .NET!
I first became aware of this excellent framework in 2008 when my boss dropped Rocky's book Expert C# 2008 Business Objects on my desk. In very short order I recognized the enormous benefits CSLA could provide to developers like myself who where trying to to produce great enterprise applications. The idea that I could create completely self-contained classes which would flow naturally between the various application layers and physical tiers made me fairly giddy with excitement. This excitement was reinforced by my efforts as I implemented user presentation layers for WinForms, WPF and Silverlight all based on the same business core with little impedance between the architectural layers or the physical tiers. Concerns such as validation and n-level undo were mostly handled by the CSLA framework with very little additional effort from the developer (me).
Then I attempted to write a presentation layer in HTML 5.
I started with ASP.NET MVC 4 because that framework is supported by CSLA and there are a variety of sample applications employing the two frameworks in tandem. I quickly found that, while you can develop an MVC application utilizing a CSLA based business core, it's almost impossible to take advantage of any of the benefits offered by CSLA from the client (i.e. browser). In the other UI technologies I'd previously implemented, object binding allowed for a vibrant user experience where, for example, clients could easily be notified when they'd made changes to an object or the object was not in a valid state. Due to the stateless nature of the MVC implementation such notification was simply impossible to leverage. Unfortunately, today's users expect exactly this type of client-side responsiveness in their applications.
I've continued building my HTML 5 application and over time I've slowly added more and more client-side "bells and whistles" all, of course, written in Javascript. What I've found is that I've functionally re-coded a large number of the business and functional rules once encapsulated solely in my CSLA business objects into client-side Javascript. I now maintain a significant number of these rules in two different code bases (and languages). My original CSLA based business objects are still the workhorses for the application when a users works with one of Microsoft's presentation technologies and they back all server-side activity but they provide very few meaningful functions when accessed through a web UI. This makes me very sad.
I had a dream of one unified code base providing a consistent experience across a variety of platforms. Over the last year and a half I've watched the HTML5/Javascript/CSS juggernaut roll onto the scene and relegate all other contenders for development of multi-platform capable applications to the fringe.
In quieter moments I can still hear the death cries of my CSLA dream. Rest in peace buddy. You were awe inspiring while you lasted.
Hello Dane... thanks for posting this article. The app development team I'm on is looking at going a similar route and I was curious as to what was the JavaScript FW that you chose to go with (AngularJS, KnockoutJS, otherJS?) or were you doing straight-up JavaScript without leveraging any FW that allowed for MV* presentation pattern... I'm tyring to raise awarness amongst my colleagues, but it seems that the HTML5/JS panacea is sweeping strongly in our shop
ReplyDeleteHi Anibal. For the project related to this post I'd employed Knockout. I was pretty happy with what that framework provided to help with application responsiveness in terms of data binding but, of course, it did nothing to help with the loss of the business logic encapsulated in the CSLA classes as they were serialized and consumed by an HTML/CSS/JS client. Shortly after this post that project pretty much hit the end of its road. Since then I've worked quite a lot with Angular (often in conjunction with TypeScript) and I've absolutely loved it. Angular and Knockout are of course not directly comparable frameworks but I've found Angular to have tremendous benefits though it does have a slightly steeper learning curve. Angular doesn't solve the frustrations I discussed in this post either but with what is essentially the deprecation of Silverlight there simply isn't a way to propagate business logic through application tiers (at least to an HTML client) in the way CSLA allowed.
DeleteHello Dane,
DeleteJust after your latest thoughts on this - 2 years on - I have a couple of Silverlight commercial apps that are written in Silverlight/CSLA. These will have to be re-written over the next few years....I have little/no MVC experience but reluctantly have accepted that using the HTML/javascript approach is the best way for apps survival (at least 10-15 years in the future).
I am very confused by the wide range of options (MVC, Web API, Knockout, Angular, Bootstrap). I can't decide which way to go (just give me Silverlight back and I'm happy as larry!!) and so as CSLA (ex-CSLA?) I was wondering what you latest advice would be? (RIP: Silverlight :()
Richard
Hi Richard
DeleteYeah, I feel your pain. As of now I still think a single page application (SPA) written with HTML/JavaScript/CSS is the closest you'll find for a web client technology which can match Silverlight. Unfortunately, there's basically nothing the two technology stacks share and, of course, you'll lose all CSLA on the client. Right now AngularJS is my framework of choice for the client-side portion of SPA apps. It can do some pretty amazing things though the learning curve is fairly steep. Angular 2 is in the works right now and it looks to improve and simply the stack significantly though it'll be an entirely new framework (i.e. no real migration path from 1 -> 2). If possible I'd wait until the release of Angular 2 and re-evaluate. If you stick with ASP.NET and leverage something like Web API you may be able to re-use some of your CSLA domain models for object validation and persistence at the service layer but the loss of the client is unavoidably painful.
As a side note I have been wondering lately if my "CSLA Dream" might become a reality again down the road. Silverlight is definitely dead (even Microsoft's new Edge browser doesn't support it) but XAML is still alive and well. With the in-roads Microsoft has made in the last couple years enabling open-sourcing and cross platform support and the steady rise of Xamarin I see the possibility that we may someday be able to write cross-platform web apps in XAML again.
Hope that helps. Feel free to reach if you have further questions (you can find my email in my profile).
Hi,
ReplyDeletejust wanted to share my feelings since I am in a similar position. Developed CSLA solution over years, now learning angular for a different application, where it would be impossible to add CSLA to. I really really miss CSLA :(
I know it is now 2016 but I'm just now doing CSLA on a new Enterprise Winforms project and I love it. I hate to hear that it doesn't work on the web but I'm going to try to stick with Xamarin for cross-platform development since CSLA.NET will work with that.
ReplyDeleteCSLA.NET could still be alive and kicking - Google article by Rocky called projecting js code from a .net Business Layer - if we can convince Rocky to agree that putting at least validation js in the business object layer we may have solved our business logic in one place issue!!!!!
ReplyDeleteWith the advent of Microsoft acquiring Xamarin I think there's a real possibility we'll see fully cross platform XAML clients in the not to distant future. Rocky has been working for the past couple years on CSLA's compatibility with Xamarin so a full-stack CSLA based application available on all platforms looks like a real possibility. Essentially the dream that was Silverlight just not in a browser.
Delete