ForumForumDiscussions and...Discussions and....Net framework ....Net framework ...Data Binding - NoNo or YesYes?Data Binding - NoNo or YesYes?
Previous Previous
Next Next
New Post
 14/03/2008 09:59


I started developing in ASP.NET2 and I use data binding with the build in controls SQLDataSource & Gridview/FormView/DetailsView. Now I have to redevelop my applications because they don't like data binding in our company and they don't like the SQLDataSource controls because they would not be flexible enough and reduce performance. I have the feeling that by using data binding I can easily use all the functionality that comes with e.g. the GridView control and it saves me a lot of time. I tried removing the data binding for one of my GridViews, but then  the GridView functionality gets lost (like the sorting and the totals). I will probably need several times the amount of time&effort to recreate my apps avoiding binding and datasource controls, so I seriously wonder whether it is really worth of it. Are there any data on the performance lost when using data binding? What are the pros & cons? Is data binding really still to be avoided or not?


New Post
 14/03/2008 10:28
 Modified By PeterVogel  on 15/03/2008 11:45:33

It's not clear to me that you will lose performance by using the DataSource controls--is there any evidence for this or is that just an assumption? It's worth remembering that the DataSource controls are just an extension of the ASP.NET 1.1 enterprise library data block which was designed for scalability. Whenever I go to write my own data access code, I remember that the code in the DataSource controls was written by the people who wrote ADO.NET. There's a lot of clever stuff going on inside the DataSources (including smart caching of data). Using the DataSource controls also positions you to use the AJAX-like properties on the GridView and DataView: EnablePagingCallbacks and EnablePagingAndSortingCallbacks. In the past 'databinding' has gotten a bad name but most (I want to say all) those concerns don't apply to the DataSources.

What flexibilty does your user want that the DataSources don't provide? There are a number of ways that you can step in and take control of the process while still using the DataSources (from my personal experience: I've found that the DataSources gave me the flexibility that I've needed but that it was the DataViews that I found too inflexible. There may be options that would give you the flexibility that you need).

On the other hand, if you're paid by the hour, having to take longer to do everything may not be a bad thing....


New Post
 14/03/2008 22:44

Hi Veerle,

I'm with PeterVogel on this one.  Back in my VB3,4,5...days I believed that data binding was the invention of the devil and should be avoided in any production code.  Microsoft are on their third or fourth attempt at getting data binding right and I no longer believe that.  The productivity advantages of data binding are too large to ignore.

It seems to me that you have your code working.  Therefore the controls must have had enough flexibility to do what you need.  If in future there really is a problem with flexibility then stop by here first.  Ask for help before you dump the controls.  The SqlDataSource seems to me to have enough flexibility for any solution where a single database query is a reasonable way to get the data.  If a single database query is not a reasonable way to get the data I would still use data binding, but I would be looking to bind to a collection of custom business objects populated by whatever set of queries I needed.

The SqlDataSource is clearly a general solution and so you can probably get better performance with a hand coded solution.  Heck - you can always get better performance.  I don't believe any perfomance loss is big enough to justify hours of hand coding to replace data binding.  In the UK you could probably hire a decent contractor for about GBP 1500/week.  For the same amount you can buy a decent spec server.  So if you have a really heavily loaded site it just might be a good economic decision to spend an extra week on hand coding.  Most of the time it's cheaper to buy another server.

As PeterVogel points out there are a lot of smarts inside those controls.  It's probably worth spending some time looking through the less common control properties, turning off stuff you don't need, and enabling stiff like caching where it's safe to do so.

So I say data binding YesYes!!!

- Richard
If this post helped you over a problem, or taught you something new, please login and rate it. Ratings are in the drop down in the top left corner
New Post
 15/03/2008 04:41

Hi  Veerle

In the past I've been reluctant to use data binding because it seemed like trade-off for convenience over performance and flexibility.  Also, before .NET 2.0, data binding meant violating a nice layered architecture because data bound controls in the presentation layer were coupled directly to the data access layer.

But, now that .NET supports binding to business objects with the ObjectDataSource, and the data controls offer so much power and versatility, it's hard to find good arguments against data binding.

There's nearly always a compromise for convenience and functionality over performance in ASP.NET, that's part of the point.  Pages would run a lot faster if we used generic handlers (.ashx) instead of using the System.Web.UI.Page (.aspx) handler, but then you might as well go back to good ol' classic ASP.

Unless your site is extremely performance critical then data binding is a big YesYes for me!  Even then, you'll probably hit a bottleneck at the database long before your ASP.NET pages.

Previous Previous
Next Next
ForumForumDiscussions and...Discussions and....Net framework ....Net framework ...Data Binding - NoNo or YesYes?Data Binding - NoNo or YesYes?

Forum Usage Guidelines

The forums are a place for all to exchange ideas and techniques, and to post and answer questions.  All are welcome to read, registration is required to post. 

If you learn somthing new, discover or acquire a new technique, then please take a moment to register and rate the post that just helped you.  This site does not send spam and it does not release your personal details.  Full details in the site privacy policy.

We have some simple posting guidelines to keep the forums a pleasant and informative environment.

  • No flames, no trolls
  • No profanity, no racism
  • Site management has the final word on approving or removing any thread, post, or comment
  • English language only please


Copyright 2002-15 by Dynamisys Ltd