Data binding in ASP.NET Whidbey
I got my first glance at Whidbey last summer. I was sitting in the convention center with about 70 other guys getting a demo of ASP.NET Whidbey (whatever the version number will be). ScottGu first stated an impressive goal for the next release: 70% reduction of the code that developers have to write for web apps! 70%, I thought, was a pretty high goal.
Then Scott showed off some of the features that will achieve that 70% reduction: Template driven sites, aka Master Pages, full support for user login, account maintenance, password recover and more controls for lots of the grunt work that is involved in building a web site.
Over the course of the presentation, Scott repeatedly said something like: This feature takes 1(!) line of code in the alpha, which is what PDC attendees are receiving, and 0(!) lines of code in the beta/RTM versions. When he said that I wasn’t quite so sure how to take that, now that I had a chance to work with some of the new features while preparing for the HOL I am very, very impressed.
Adding these features like, user login, password recovery or site counters can all be done from the IDE. You literally no longer need to write any lines of code, not even the SQL set up and manage user accounts in a database. The new IDE presents Smart Tags and Wizards for all these tasks.
One of the truly sweet new features is the new DataSource architecture for data binding. The different flavors of the DataSources allow you to bind to all sorts of different data sources (duh!). DataBinding is no longer restricted to DataSets and Collections (Yes, generic collections work as well). Because my pragmatic side understands that there are situations where it is appropriate to bind the content of an XML file to a web control, even though it’s not promoting good architecture. The DataSetDataSource and the XmlDataSource are the two new classes that facilitate this.
Yet, the architect in me is much more excited about the improved support to use databinding with tiered apps. The key piece of this support is the ObjectDataSource, which does exactly what it sounds like. It exposes arbitrary objects as a source for data. You simply specify the class that acts as the source of your data, you specify the methods on that class that perform the operations to retrieve and update that data source and you are ready to go.
While you still have to either write code or use the mundane UI of the property editor, the beta will actually present full UI support (keep the 70% goal in mind) to bind to objects. Now fans of well designed applications (like myself) don’t have to agonize over using databinding because it’s easy but not elegant! You can architect abstract all you database access into its own tier, layer your business tier on top of it, work with custom classes and strongly typed collections (thanks to generics) and still use databinding.
If you want to see more, come to the HOL area and try it out! See you there.
UPDATE: PDC is over, but more presentations and the HOL exercises are available at http://www.asp.net/forums