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

Personally, I think that it depends on the project. If its a small CRUD application with a couple of pages, then binding to an object datasource will probably be quick, easy, and have little consequences.

If it's a large scale application with tailored needs, then you may find it frustrating trying to make an object datasource meet those specific needs.

Answer 3

The more and more familiar you become with the underlying ADO.NET framework used, the less and less you will come to rely on the data source controls that are packaged with Visual Studio. I used them religiously on the first few .NET projects I worked on, but I quickly found out that I would be much better off just using the fundamentals of connecting and retrieving data on a database than I was in relying on .NET to make its best attempt at doing it for me.

I look at them more or less as training wheels to get you familiar with the life cycle of databinding more or less.

Answer 4

In my opinion both have their place, their strengths and weaknesses. The time saved coding the elements you mention, particularly paging and sorting, are big helps, but if you want to do anything remotely interesting with them, they quickly become pains to deal with.

I use ODS when the data will be strictly used for display only. Slap in a data grid, an ODS, and you're done. But if that data needs to be manipulated in any way, I stay far away from all of the built in pieces, no grids, no ODS.

Answer 5

I think in general, code behind is more useful because it provides a central location for customizing data layer connections. As long as you divide the action into different layers, code behind can be very scalable.

Custom object datasources, on the other hand, are very useful because it allows for inherent binding with the GridView control. The dataset provided by custom object datasource allows for easy sorting and paging. The custom object also provides a central location for data layer access.

Answer 6

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

Answer 7

Hi guys - I'm wondering about the pros and cons of using multiple ObjectDataSource objects on a page and the cost on memory/performance.

I'm currently building a page which has circa forty drop down boxes; the approach with the project is to use ODS for all binding, but I'm conscious of the cost in doing so in this scenario. Am I better off using standard ADO.NET approach for increased memory/performance reasons?

Thanks in advance