This post brings together the series of data source related posts (given my site has been down for the last few days, it might be a good idea to have a followup post). I hope they have been an interesting read, and also hope that the progression gives some sense of how one can incrementally build controls in general (in order to handle the inherent complexities associated with these beasts... er... tasks).
On the left is a screenshot of a Weather Applet (the applet doesn't show the data source - it is after all non-visual, but I've added it since provides some visual clue of the scenario, and I couldn't resist adding a pretty picture. :-)
- Part 1 covered the basics of the data sources control architecture. I also wanted to get out the idea of packaging web service APIs that are starting to get popular into higher level controls, so as to enable a RAD programming model for them.
- Part 2 covered using parameters to enable declarative transfer of values from other parts of the page into the data source and using them to automatically cause data-binding when the underlying values changed.
- Part 3 introduced an async data source framework, and how it could be used to perform async data access in order to optimize server CPU usage.
- Part 4 introduced encapsulation of cache usage within a data source, as an even more effective technique to optimize not only server CPU usage, but also end-user experience.
- Part 5 finally showed the design-time experience enabled by data source controls by virtue of live data and schema.
For those who have been patient through the progression, here is the sample application and code. As usual, I appreciate any comments on this series... What do you think about data source controls, or the general model? What do you think about these sort of topics?
By the way, I just noticed John Gossman has been reading my posts, and mentioned comparing ASP.NET data sources to similar concepts in Avalon. I would love to hear more details... Based on some early experimentation, I personally noticed two key architectural differences - there is loose coupling between data sources and data consumers in Avalon... instead the coupling is at the actual data level (in fact any component with properties can be a data source for another component). Secondly, in terms of bindings themselves, Avalon's bindings are live (listen to change notifications). In contrast ASP.NET bindings pretty much execute once, where the framework is optimized for a linear page lifecycle coupled with a model where user input is processed at the start, and then there is no more of that, until a new page is rendered. I do love Avalon's data-binding model - I think it lends itself very well to declarative programming... and I am a big fan of that. In fact Ajax-ish applications are more like Avalon, since they feature the same live environment where bindings need to be live, and the coupling between objects is at the data level. We're heavily borrowing from Avalon-ish data-binding framework for the Atlas project.
Posted on Monday, 7/25/2005 @ 12:00 AM
| #
ASP.NET