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?

Caesium

Answer 1

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

Cagliari

whilst I agree with all of your points and your answer is well written, your pages mught now not depend on the details of your database, but your business objects do. What advantage does this bring? – Ultramicrometer

The advantage is: if your database changes, but your business objects stay the same, the UI still works. If you use SqlDataSource directly, and like many do, use a SELECT * FROM .... your code will most likely crash the second another field is added to a database table. This will not be the case if you have a business layer in between. – Cagliari

Also, by packaging up your data into business objects, it's much easier to work with them. You have e.g. a "Customer" object, for which you can read and write properties like "CustomerID", "Name" and so forth - you don't have to deal with the intricasies of database rows and fields and do all the conversion everytime you access some data. – Cagliari

But I agree - you now have a dependency on the business object layer - you can't talk that away in any way, shape or form. But it might just be less of a dependency (less direct, less friction). – Cagliari

@Cagliari - great answer. I asked the question more for additional info the OP rather than for myself :) – Ultramicrometer

Answer 2

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.

Lambart

Answer 3

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

Nuke

Answer 4

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.

Layoff

If one did choose to go the route of using ObjectDataSource in their ASP.net application(s) what modeling tools/code generators would you recommend? Free and Commercial if you know of any. I have never utilized tools such as these as I have only recently become involved with ASP.net. So far all of my projects have been direct SQL as my apps have been tools as opposed to End User Apps. – Marcellus

Answering that may be a violation of some rule but I believe in helping people more than following rules. I use a tool by SoftFluent. Used to be called CodeFluent Entities believe it's now just called Code Modeler. It's commercial but relatively inexpensive. If you work for non-profit they may give you a free version. There are templates for building an entire application (UI). I only use the templates for building the object model, methods, validation rules, etc. – Layoff