Thursday, August 24

SqlDataSource Vs ObjectDataSource

Here are the arguments
Unsuspecting programmers, it is claimed, will use the SqlDataSource control and unknowingly commit the unforgivable architectural sin of mixing their user interface, business logic, and data access layers.

The SqlDataSource control enables you to represent a database connection, and common database commands, declaratively. Simply by declaring an instance of the SqlDataSource control in a page, you can represent SELECT, INSERT, UPDATE, and DELETE commands which can be executed against a database.

SqlDataSource control is considered "really, really bad" is that it encourages programmers to flatten what should be many into one. The SqlDataSource control mixes business logic and data access layers into the user interface layer.
Mixing the data layer with the UI is a BAD idea, period. Sure there may be times when you can get away with it, but the eventual unmanageability of it will greatly outweigh the short-term productivity gain. Creating logical layers of abstraction doesn't require physical separation of layers. Just moving the DAL into a separate class is a good idea because it gives you a single place to look for code dealing with the database. In the SqlDataSource scenario, if you change a stored procedure that is used on more than one page, you have to track down every page to make the change. This is bad design incarnate.

Behind the scenes the SqlDataSource control generates the ADO.NET classes (Datasets, SqlCommand, etc.) that is necessary to access the data defined in the control's markup. But what about reuse? If I'm calling a stored procedure with several parameters through a series of page requests, it would be nice to get some reuse from the parameter collection ala Data Access Application Block's parameter caching.

The ObjectDataSource control however does provide an architecturally sound way to bind web page controls to a middle-tier (logical, not necessarily physical) layer. So, for those web developers out there who want the ease of use that comes with declarative data binding, I recommend they use the ObjectDataSource control and forego the SqlDataSource control altogether.

I think as a best practice, one should always use ObjectDataSource since it allows us to seperate the business layer logic from the UI and follows the MVC.

I came accross this because I wanted to sort a GridView. I was assigning a DataTable returned by a method to the GridView's datasource. If we create a explicit DataSource object and bind the GridView to it then the gridview is able to talk to the datasource and takes care of the sorting/paging.

The object datasource helped me to grab data from a stored procedure and hence with zero sql code in the UI and kep it clean.

Microsoft is finally "getting" MVC. Great post. Very informative. I like the way that you can write a reusable, statless business object and assign it to the ObjectDataSource control. Very clean separation.
This comment has been removed by a blog administrator.
So much of existing code has UI and business layer mixed. I guess only with new enhancements and new projects can we start implementing tje best practices, since billable time counts.

Let post some stuff about some best practices.
Post a Comment

Subscribe to Post Comments [Atom]

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]