The Dark Side of Declaritive Databinding

Most people who have talked/worked with me know that I am not the biggest fan of the demoware databinding techniques. When choosing to implement databinding in your application you have to decide what you will use as a data source. Of the many sources of data that can be bound to, the most common are

<?xml:namespace prefix =“” o /><o:p> </o:p>



-Custom Objects

<o:p> </o:p>

I am going to (eventually) focus in particular on the use of the Custom object scenario. I will, however, start by using datasets as for the purpose of contrasting it to my approach. In my first attempt at databinding I will utilize some of the new controls made available in ASP.Net 2.0, namely the new Data Source Controls. Here is the markup required to configure the SqlDataSource control as well as an accompanying gridview to display the information.

<asp:SqlDataSource ID=“customersDataSource” <o:p></o:p>

runat=“server” <o:p></o:p>

ConnectionString=“<%$ ConnectionStrings:DatabaseConnection %>” <o:p></o:p>

SelectCommand=“SELECT * FROM Customers” />

<asp:GridView ID=“customersGridView” runat=“server” DataSourceID=“customersDataSource” <o:p></o:p>



<asp:BoundField DataField=“CompanyName” HeaderText=“CompanyName”/><o:p></o:p>

<asp:BoundField DataField=“ContactName” HeaderText=“ContactName”/><o:p></o:p>

<asp:BoundField DataField=“ContactTitle” HeaderText=“ContactTitle”/><o:p></o:p>

<asp:BoundField DataField=“Address” HeaderText=“Address”/><o:p></o:p>

<asp:BoundField DataField=“City” HeaderText=“City”/><o:p></o:p>

<asp:BoundField DataField=“Region” HeaderText=“Region”/><o:p></o:p>

<asp:BoundField DataField=“PostalCode” HeaderText=“PostalCode”/><o:p></o:p>

<asp:BoundField DataField=“Country” HeaderText=“Country”/><o:p></o:p>

<asp:BoundField DataField=“Phone” HeaderText=“Phone”/><o:p></o:p>

<asp:BoundField DataField=“Fax” HeaderText=“Fax”/> <o:p></o:p>




<o:p>And here is the app in action:</o:p>


<o:p><?xml:namespace prefix =“” v /><v:shapetype id=“_x0000_t75” coordsize=“21600,21600” o:spt=“75” o:preferrelative=“t” path=“m@4@5l@4@11@9@11@9@5xe” filled=“f” stroked=“f”><v:stroke joinstyle=“miter”></v:stroke><v:formulas><v:f eqn=“if lineDrawn pixelLineWidth 0”></v:f><v:f eqn=“sum @0 1 0”></v:f><v:f eqn=“sum 0 0 @1”></v:f><v:f eqn=“prod @2 1 2”></v:f><v:f eqn=“prod @3 21600 pixelWidth”></v:f><v:f eqn=“prod @3 21600 pixelHeight”></v:f><v:f eqn=“sum @0 0 1”></v:f><v:f eqn=“prod @6 1 2”></v:f><v:f eqn=“prod @7 21600 pixelWidth”></v:f><v:f eqn=“sum @8 21600 0”></v:f><v:f eqn=“prod @7 21600 pixelHeight”></v:f><v:f eqn=“sum @10 21600 0”></v:f></v:formulas><v:path o:extrusionok=“f” gradientshapeok=“t” o:connecttype=“rect”></v:path><o:lock v:ext=“edit” aspectratio=“t”>ScreenShot1</o:lock></v:shapetype></o:p>

On the surface this all looks great. I’ve developed a fully data driven web page in under 2 minutes and didn’t have to type a single line of code. What could be wrong with that?

First, the use of the SqlDataSource control requires that the view have initimate knowledge of the database. The view is responsible for determining where to pull the data from as well as how to display that data. And if it were not for the fact that the connection string was stored in a configuration file, then it would also be responsible for providing a connection string used to connect to the database. This is just plain old poor separation of responsibility.

Second and no less important. One of the biggest problems with this method of databinding is the fact that you have to run the application in order to verify that the databinding will work. I’ll prove this by making a small change to the db schema. I’m going to change the name of the ‘Customers’ table to ‘Customer’. I’ve made the change and rebuilt the db (using Nant of course!!).

Now I’ll run the app.


Ouch. And to add insult to injury; the only reason I found this error was by running the app and navigating to the page in question. Not efficient.

This is all too common a scenario I experience when going in to mentor teams of developers who are strong proponents of a data-driven approach to application development. One small change can cause ripple effects which are often not realized until the application is run. This is a very slow process and is not conducive to rapid, confident development of application functionality. In future installments I will talk about ways to handle this issue with a bit more style and grace, using a TDD perspective!!