I'm just curious if anyone has played around with this at all.
For client interactivity, I see two main routes - client side validation (and likely duplicated to some extent - I don't think it can all be automatically generated - some stuff sure) or some nice implementation of Ajax technologies.
I did a little test that involved storing a Csla business object in a session variable along with an array of PropertyInfo[] (I wanted to not have the GetProperties be a hit on each Ajax call for my test).
The testing page iterated from 0 up until the max # of properties, performing an Ajax call for each and every property - once the response was "DONE" instead of the property name and value, it stopped and gave me the results - # of ajax calls, avg ajax call time.
When run on my PC (no network latency) the avg ajax call time was 30ms. Within our lan it was 200ms, which seemed really high. From a server 1000mi away it was 300ms.
It seems to me like the ultimate in responsiveness for object editing would be some manner of Ajax calls that would occur with control changes (most of them likely resulting in an empty response and no action) that would almost perform like an "itemchanged" - each Ajax request sending back a response to the page as to what the page should do to alter itself. i.e. disable control c1 and c2, hide control c3, put value in control c4... the business object (stateful) would be brought in from a cache of some sort, manipulated, and then based on changes within the object construct a response in some particular format.
I'm really just getting my feet wet with Ajax but I'm curious if anyone has delved deeply into using Ajax with Csla Web applications.
Thanks!
One thing to keep in mind, between '96-'97 and today there have been significant improvments in our connectivity so it's possible even an MTS solution would show significantly better performance today. BUT, that being said, benchmarking is only as good as how accurately the testing reflects real usage. skagen00, did your test include dial-up speeds, broadband, DSL, T-1...??? Will your users be limited to a high-end technology or will you have to account for those with slow connection speeds that will adversely affect your results?
In our case, most of our work is exposed to a wide audience so we have to account for those with dial-up speeds. The level of interactivity you are referring to does work for them but because of their greater latency, the end result is undesirable as it makes the app appear sluggish for even the most basic task.
For us, as desirable as it is to make our web interfaces as responsive and interactive as their Windows counterparts, these latency issues make going to the extreme with AJAX unrealistic. So, we still make use of a very rich, OO, javscript, client-side library to provide as much of that interactivity on the client as we can. If an application requires or a customer requests a higher level of interactivity, there's always the smart-client route as well. But, since most of what needs to be communicated between client and server is data and not behavior, this is not a problem when you can encapsulate the behavior into your javascript library (kind of a client-side CSLA, if you will). Then AJAX handles sending and receiving the data to drive the behavior.
We had a similar inquiry when first looking into AJAX with regards to validation. If our validation rules are in our BO's on the server, isn't it additional work to reproduce them on the client? Well, yes and no. First, if you design your UI components and javascript objects to handle these rules right out of your BO's, then it will require no additional programming to implement in your applications. Second, even Microsoft says in their "how to"s for developing server-side controls, etc. not to trust client-side validation and to always double-check submitted data before processing. Because of this it makes complete sense to duplicate efforts by having both the client and server handle validation. If the client does what is expected, your user gets the higher level of interactivity you are after while still protecting yourself on the server from mischief and allowing your BO's to do their thing when data is posted.
To accomplish this, imo, it is better to reproduce your validation rules on the client rather than using AJAX to call back to the server to perform the task. As nice as AJAX is, going too far with it can actually degrade the overall performance of your applications as you've increased the total number of round-trips your server must process, albeit smaller packets (hopefully) it is still traffic, and you've made your interface more dependant on these smaller postbacks potentially stalling the interface if there are latency issues.
As with any technology, moderation is key. AJAX should be used where appropriate and where it gives a true benefit to the solution - not just because you can.
Now, if you are developing an intranet application on a local network where connectivity and latency aren't issues, all of this goes by the wayside and have fun...
Hope that helps.
Thanks for your replies, both.
Our system will be likely used internally in a LAN 99% of the time - to where I could realistically but not likely ignore the problems of dial-up users. My test involved all high-speed access, one from my PC, one from another PC in the lan and one from a PC out on the east coast. For my test I just wanted to get a feel for how fast these turnarounds would be. I think for internal apps it may not be unreasonable over time to expect high-speed access, but obviously we're not there just yet.
I definitely appreciate the pitfalls of AJAX as you stated them - but there will be a point where it will be possible to have this sort of experience. I am just trying to keep an open mind and think in an ideal sense and determine the feasibility. I'm not entirely convinced that it's not possible to pull something off in this area (assuming majority LAN access and mostly high speed for this internal system - I think you stated something as such at the end of your post).
(And BTW, I'd love to do smart client - not an option for me).
At this point I'm looking at some of the Infragistics control library, as there's certainly a lot of asynch functionality in some of their components.
Thanks again both.
You may try the Telerik RadControls library as well (www.telerik.com). They have an extensive array of AJAX enabled controls that require virtually no coding or even understanding of AJAX in order to use them. We have successfully integrated the control suite into our CSLA based application suite.
Izak
As far as Infragistics goes, a single control may have a manual that is longer than Rocky's book.
And quite a few of their controls get so big that displaying them is a lot like coughing up a hairball over your network.
That said, they do have some nice features. I'm using them when they have some unique feature I need (and lack the time to duplicate), but I'm not using them for routine pages when I can avoid it.
Copyright (c) Marimer LLC