CSLA and SPA / Hot Towel

CSLA and SPA / Hot Towel

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

fmongeau posted on Tuesday, February 26, 2013

New member here.

We are using CSLA in WinRT (switched from Silverlight) (since fall 2012) with Kona (recently) and loving it all. Great work and thanks.

(Bought all the books and videos Big Smile  , great learning tools!)

While we are getting the hang of it in C# etc, I'm watching with interest what John Papa is doing with Hot Towel and Breeze etc... I am not a JavaScript HTML5 ASP guy so I need to ask what may look to some as a 'silly' question.

In a LOB app, would it make any sense to use Hot Towel on the client side with CSLA on the server side ?

I'm asking in light of all the uncertainties with Windows RT (sideloading LOB apps and all, as we all know). Perhaps a LOB app should use something like Hot Towel, Breeze and Knockout etc ... on the client and CSLA, Azure and SQL Azure on the server side. With Silverlight and now the sideloading stories, you would think MS is trying as hard as it can to push LOB developpers to the 'other side'.

Thoughts are well appreciated. Thanks.

RockfordLhotka replied on Wednesday, February 27, 2013

Welcome to the forum and community :)

This is certainly an area I've been giving a lot of thought over the past few weeks/months. It has come up in a couple other threads and one or two of my blog posts as well.

There are perhaps three primary ways to approach the challenge.

  1. Accept that the SPA model is really an SOA play, with a client app and a service app communicating via messages, in which case you'd write the client app with h5js and the service app with C# and CSLA
  2. Decide that n-tier is more cost-effective and simpler than SOA and view the client as a projection of the server-side app code (much like people do with ASP.NET MVC validation rules). In this case you can envision server-side helpers that emit fairly rich js code based on the CSLA business objects, and a variant of the data portal that communicates between this emitted js on the client and the code running on the server
  3. View all of .NET as "legacy" and move entirely to js, using node.js on the server and various h5js libraries on the client. Today's CSLA has no play here at all because there's no use of .NET at all, but you could envision a pure "csla.js" framework that also had nothing to do with .NET and existed purely as a pair of client-side and server-side js libraries

It is all interesting to think about, but I haven't _acted_ on any of the above yet because I'm still maturing the WinRT/WP8 support in CSLA.

I really want to explore option #2 because I think it might offer a good way to leverage a lot of existing skills and people's business code, while eliminating any dependency on a Windows client.

Ultimately though, for h5js to displace Windows as a smart client dev platform h5js needs a standardized way to package, deploy, and update smart client apps that work offline. I suspect that'll take years to evolve, and in the meantime people like me who spend a lot of time offline (airplanes, rural areas) will find native apps far more appealing than h5js apps...

fmongeau replied on Wednesday, February 27, 2013

That does make sense. (I'm also glad to see that my Q was not so silly!)

I fully agree that option #2 needs to be explored (sadly; because of MS policies), no rush surely but... if MS does not get their act together (sideloading, costly upgrades to Win8/RT, awful deployment model ...) that will be a very viable option. I do hope that we will not get to option #3.

I confess that I do not understand/grasp your last paragraph. I think that LoB apps are only (well almost only) useful 'on line', whether they are h5js or C#/XAML. It is very costly to build LoBs that work off-line and it's not what users want anyway (they feel their data must be up-to-date - my customers do anyway). Then, there is the trend that being "on-line" is getting easier and more convenient everyday (even airplanes now provide wifi, more and more); very soon you'll be on line 24x7 everywhere (things tends to evolve more quickly than we can imagine - on the HW side definitively). As for deployment, I can only feel we have taken a step backward with this sideloading/app store non-sense compared to the Silverlight deployment model. Now that was something else! The good old days! :)

Please keep us updated on your musing on option #2. .... and also please, please speak up in a loud voice for us all when you deal with MS about this sideloading issue (as you so eloquently discussed in your blog). Somebody in charge over there need to see the light! Gee, bring back Bill G for G...'s sake! It's time for a 'bet the company' move now! Thank you for your work and support.


TSF replied on Wednesday, February 27, 2013

John Papa's work on detailing the SPA approach is very helpful. I just started working on a web version of a WinRT/CSLA app I published in the store a few months ago, and I'm going the MVC / CSLA approach. (PluralSight has been a excellent resource for this.)  It would be great to have CSLA emit the Js needed for client side validation.  But the Js libraries that are included in the MVC 4 project template definitely help to get one off to a good start on creating a reasonably rich web client.

fmongeau replied on Monday, March 04, 2013

Talk about timing! I just read you Feb 14 and Feb 26 blog posts. I guess my concerns (above) are timely and shared by the community.

I can't add much to everything you wrote (very well explained) but just want to thank you and beg you to keep pushing the MS folks on this issue. Time is running out quickly; the race is on. We may soon have NO choice but to go the "h5js side".

PS. Hope to meet you at Modern Apps Live!

Copyright (c) Marimer LLC