As I present topics on ASP.NET 2.0 at conferences, webcasts, and courses I am often asked, after presenting declarative data sources, if I like the new declarative data source model. This question is usually asked with a tinge of disbelief and skepticism, as if perhaps I’m presenting the new model as a matter of course, but in reality I never personally intend to use it in any real-world application, and will secretly scoff at those that do.
The truth is I do like them. I’ll admit that it took me a while to adapt to using them, and I had my doubts about performance and flexibility, but after spending some serious development time with them, I’m actually quite pleased with the effect they have on the overall codebase of an application. This didn’t happen overnight, however...
In order to better understand how to use them, I decided to try and use nothing but declarative data binding in a recent project – even if I could see a quicker solution to a problem by resorting to programmatic binding, I would spend the effort and try and make it work with declarative data sources. As I progressed through the project, I first found I was always able to make declarative data sources do what I needed, mostly because I knew that I could always resort to an object data source to bridge the gap. Secondly, I found an interesting pattern arise in my use of data source controls. I would often start by using the SqlDataSource with its embedded SQL. For a fair number of simple pages, this was completely sufficient. On pages where it was not sufficient I would create a simple data access layer that returned DataTables. Such a data access layer can be bound using an Object data source, and loses none of the functionality you gain by using a SqlDataSource, but you now have programmatic access to the methods that are invoked. This was critical for doing things like temporary impersonation where I needed to begin impersonating the client before any data access calls (or web service calls) were made, and then needed to clean up and undo the impersonation after the calls were made. Then there were other places in the application where I was attaching to a full data access layer complete with entity classes and business logic, where I used the object data source to interact with the classes. In my mind, there is a spectrum of data binding that you can pick a point on based on the requirements of that part of your application that looks something like:
In the end, what I liked the most about this model, was that I was never tempted to put any data-specific logic into a page, it was always relegated to a data access layer and accessed through the object data source. The code in my pages was then guaranteed to be nothing but UI logic, a very clean and complete separation.
Btw, if you’re just beginning to explore declarative data sources, Nikhil Kothari has a nice 5-part blog series discussing many of the details:
Posted
Aug 09 2005, 01:44 PM
by
fritz-onion