SqlDataSource vs ObjectDataSource

Question

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 1

if you can applay your business layer code in the stored procedure the its better to use SQLDataSource

Answer 2

In theory objectdatasource is better. But that all depends on how well the object model is written and documented. We outsourced a company that used a custom code generator (which they would not provide us with) to produce all of the layers. It turned out to be nightmare to make even small changes such as adding a property or changing a field type. I am now scrapping virtually everything they did and just using the stored procedures they wrote.

My long term goal is to re-write the application from the ground up using a commercial modeling tool & code generator. If you are going to use objectdatasource I highly recommend finding a good modeling tool that includes a flexible code generator.

Answer 3

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

Answer 4

If you have a business layer that you're using in your projects, ObjectDataSource is the natural choice. This fits well with many ORMs, and many of them provide additional benefits (validation, undo, etc). It also lets you access any of the other properties & methods you have on your business objects - not just the direct SQL fields. This can come in real handy when binding - since it allows you to just bind to properties in the markup instead of having to write a lot of code behind.

If you are going this route, mixing SQLDataSource and ObjectDataSource can lead to confusion by the next developer to pick up your project. In this case, I stick with ObjectDataSource for code consistency.

If you don't have a business layer and are just hitting SQL directly - use the SQLDataSource. My personal preference is that all of your SQL code should be in a business or data layer, and because of I almost never use SQLDataSource.