SqlDataSource vs ObjectDataSource

.net asp.net objectdatasource sqldatasource
Dumb Questioner picture Dumb Questioner · Jul 30, 2009 · Viewed 10.6k times · Source

If a web page needs some data, why not just have a SQLDataSource call a stored procedure? Why use an ObjectDataSource to call a business object that then calls the stored procedure? I understand that other apps (lets say desktop apps) built on the .net framework can access the business objects, but what if the application will always be only a web app?

To be more clear:

When should one use an SqlDataSource or ObjectDataSource?

How does one motivate the choice?

Answer

marc_s picture marc_s · Jul 30, 2009

Having just a SQLDataSource is perfectly valid, if it's just a demo, a prototype, or a quick hack. It's fast, it's easy, it just works and gives you the results you need.

However, when an app is designed and built for the long run, and anticipates that things (requirements, customer wishes, eventually the database schema) may change, then it might make a whole lot more sense to introduce a proper "business" layer - model your business objects as objects, and then provide a mapping from the underlying database to those business objects.

As the saying goes - you can solve pretty much anything in computer science by one more layer of indirection (or abstraction) - same holds here.

SURE: you can go straight to the database, and sure, at first and for the first iteration, that's possibly (or probably) the quickest way. But in the long run, when an app is built to last, it's usually a quick-and-dirty way - the cost of upkeep, the cost of maintenance, the cost and effort needed for changing according to your and your customer's needs will grow and quite quickly, that quick'n'dirty solution doesn't look so great anymore, in terms of effort.

So to sum up my point: yes, initially, using a direct SQL Data source might be quicker and easier - so use it when that's the important point: to get things done for a quick demo, a proof-of-concept style app. But in the long run, when you look at the life span of an app, it's usually worthwhile investing a bit more (design and coding) effort to add this layer of abstraction so that your web pages don't directly depend on the details of the database underneath.

Marc

Related questions

Using ObjectDataSource and DataObjectTypeName, How Do You Handle Delete Methods With Just An Id Parameter?

If I have an ObjectDataSource setup like: <asp:ObjectDataSource ID="ObjectDataSource1" runat="server" DataObjectTypeName="Employee" InsertMethod="Insert" UpdateMethod="Update" DeleteMethod="Select" TypeName="EmployeeDB"> </asp:ObjectDataSource> and a data/business object with methods like: public class EmployeeDB { …

Read More
The type "..." is ambiguous: it could come from assembly "..." or from assembly "...". Please

I'm developing a Web Application on Visual Studio 2013 and I have the next problem: The type 'AddressMaintenance.App_Code.DAL.DataSetTableAdapters.VALUESTableAdapter' is ambiguous: it could come from assembly 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\47…

Read More
In C#, what is the difference between public, private, protected, and having no access modifier?

All my college years I have been using public, and would like to know the difference between public, private, and protected? Also what does static do as opposed to having nothing?

Read More