Data Access - The SqlDataSource Part 3
In the previous posts we dropped a table from the Server Explorer onto our design surface and saw how a SqlDataSource was created with T-SQL statements to populate the basic functions of our control. In the second part we replaced our T-SQL with stored procedures and saw how this can help us maintain our code. However this is method still tightly couples our presentation layer to our data layer (what there is of one). While I'm not comfortable saying this is always wrong...it's definately not always right. For RAD (rapid application development), quick prototyping and short lived specialized applications this may be sufficient for you. However if your application is going to be maintained and grow over a longer period of time, you will quickly find that the SqlDataSource will become a sticky issue.
Consider this scenario: You have a dropdown list of some value on your page that you want to populate with data from a SqlDataSource. So you write a stored procedure to return your list. You add the SqlDataSource to your page. Add your dropdown list control and bind it to your datasource and blammo...working page. Two months later a business rule has sprung up that certain values from that list will be excluded based on other conditions within the application. Let's assume for a moment that those "conditions" are unique to the user that is currently logged into your application and are not persisted in the database. Meaning that we cannot use our stored procedure to limit the result set. Now we are forced with overriding the binding behavior of our dropdown list. I personally avoid overriding the behavior of standard controls in all but the most necessary scenarios. In my view it leads to very difficult to maintain code. A 'better' solution to this is to create a business object that controls the data being returned to the application, and then the application doesn't need to do anything fancy it just binds that data to the control.
It all comes down again to seperation of concerns. The Data Access Layer (the database and objects that get data from it) does data access, the Presentation Layer (the html/windows form) presents, and the Business Logic Layer (classes that sit between the Data Access and Presentation layers) makes all the decisions. While this is what is highly desired there are practical reasons that these roles blend from time to time...the key is to limit them whenever possible. I prefer to have all my presentation layer pages (or Windows Form Elements) be as 'dumb' as possible. So in the scenario above the SqlDataSource lets us down in that regard. However, having said that there is a time and place for everything so knowing the basics of how to use them is essential.
Mark Twain said: "To the man with a hammer, everything looks like a nail." Don't let SqlDataSource be your hammer. Likewise remember that it is there and can help you with some tasks.
I'm going to leave the SqlDataSource alone for a while and in the next post I'll start discussing the ObjectDataSource and building some basic classes and show you a couple of fun and easy data access patterns.