Object datasource or code-behind: which is better?

Question

I know that it's a subject that can raise a lot of debate, but I'd like to know what people think the various pros and cons of using Object Datasources are. I'm doing a project right now with another programmer who's experience and comfort level are all rooted in classic ASP, and I'm unsure of which way is going to
a) get the job done quickly b) get the job done with a minimum of fuss

We have a nice repository layer with domain objects capable of self-validation, so the methods are in place to do either the ODS binding, or code-behind binding.

I dislike the ODS for most of the obvious reasons, but if it does save me from having to hand-code paging/sorting/selecting/inserting/updating/deleting scenarios, then can it really be that bad?

Answer 1

Object data sources are nice for small projects but they do not scale well as you are embedding data-layer information in the UI layer of your application. I would suggest that you only use them for very small applications and scratch-pad testing stuff. If you make a design decision to use them be prepared to struggle with scaling and maintenance issues in the future.

Answer 2

The biggest benefit of DataSourceControls is that they abstract away several concerns about the .NET lifecycle while providing support for full CRUD and two-way databinding expressions, i.e. <%# Bind("FirstName") %> (however 2-way data-binding does kinda suck so you're probably not missing out on anything). As a design pattern, it's a pretty good idea with a mediocre implementation (much like WebForms itself).

If you disable viewstate and find yourself trying to figure out why your postbacks aren't being handled, or you end up having to call DataBind() in several places, data sources can take away some of the headache, because the DataBoundControls are smart enough to know when they need data and they just demand it from the data source. No DataBind() calls necessary.

DataSources also provide a nice way to handle sorting, filtering, and pagination. Most developers, when they use code-behind, don't usually do pagination and instead end up returning huge result sets from the database.

The downside of data sources is that there haven't been many good implementations. And usually you end up tying your web UI to your persistence implementation (i.e. SqlDataSource, LinqDataSource, etc) or you end up using ObjectDataSource, which sucks because it is so limited, requires you to hard-code class names and method names into your ASPX, and uses reflection somewhat inefficiently. Because of this, it not useful for people using dependency injection or static DAO classes. It's a pretty poorly-conceived class and seems almost like an afterthought by MS.

Personally I would prefer to use DataSources AND the code-behind. Use a DataSource to take away the lifecycle/viewstate headache, and then provide it with a "Select" event/delegate in the code-behind. Unfortunately ObjectDataSource can only use reflection, however you could easily write your own implementation. I have one of my own but it is not public. However before I wrote it I used this, which makes up for some of ObjectDataSource's inadequacies:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html