Wrox Programmer Forums
Go Back   Wrox Programmer Forums > .NET > Other .NET > ADO.NET
ADO.NET For discussion about ADO.NET.  Topics such as question regarding the System.Data namespace are appropriate.  Questions specific to a particular application should be posted in a forum specific to the application .
Welcome to the p2p.wrox.com Forums.

You are currently viewing the ADO.NET section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
Old January 3rd, 2007, 09:04 AM
Registered User
Join Date: Jan 2007
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Default Bound Vs Unbound controls


My question is a generic question about bound vs unbound controls.
I am new to .NET. For now I am learning VB.NET 2005 from wrox books with emphasis on database programming using ADO.NET. The examples that I have seen so far were primarily using bound controls (that is bounded to base tables)
Should front-ends have bound controls at all? Say, you have SQL server as a back-end with your database and you want to build a front-end. Will you build your application with bound controls or is it better to build your application with unbound controls (that is, do not bound your controls to base tables at all). Instead have a one "I/O" class where all interaction with the back-end is done. That class serves your different data entry forms and your reports.

Which way would you recommend and why?

Old January 16th, 2007, 01:40 PM
Friend of Wrox
Join Date: May 2006
Posts: 643
Thanks: 0
Thanked 0 Times in 0 Posts

In .NET the bound controls are not bound to the database, but rather to DataTables/DataSets which are disconnected from the database. These datatables can be based on "base tables" or on any sql query that might be joining tables and "filtering" the data. You can still have one data access class (or more likely, component) that does the actual interatino with the database and use data bound controls as well.

Additionally, in .NET bound controls can be bound to custom objects and XML as well. If you want to have updateable functionality, that can also be accomplished using bound controls.

So now the question is... is this a good model to use? IMO, that is a personal preference. In a RAD environment where you have a strong design model based on binding controls in some easy to implement manner (such as using metadata to dynamically set things up, for example) so that very junior developers could then just make sure they have the right controls on the form and the correct "wiring" hooked up to the metadata then perhaps data binding is a viable pattern. For example, in a tight Model/View/Controller design the model would make available all the data that the view needs, and the programmer for a specific view would merely drop the appropriate bindable controls onto a form and wire it up to the controller and/or model as per some standard practice. You have to buy in to the event model of the controls you are working with to capture the users intent, and this is where it can be a hassle - at least in the old days. With all the advanced thinking that has gone into these newer bound controls it might be that you'll find it to be actually easier to use bound controls once all the kinks are worked out.

So, here is my take on it: I have never been fond of bound controls, but have recently found ways to use it to quickly throw together desktop apps that connect to a local datasource (that is non client-server or n-tier apps) and not give up any control or have to buy into complex and buggy event handling schemes to validate or otherwise manipulate data. I still prefer non-bound controls for custom stuff and any n-tier applications - but that could change since most of what I have previously done is try to implement my own "binding" mechanisms since the store-bought ones were never complete enough or bug-free enough or hassle-free enough...

I have worked on projects where the code was hard to work with and especially difficult to maintain and enhance due to business logic in the UI. Typically, when developers use bound controls they end up putting a lot of business logic into the click events, change events and so on, so when rules change it is difficult to ferret out all the places in the code that need to be touched. As long as the application is coded to take these things into consideration then bound controls are just another tool in the toolbox. I guess the issue is that it is often the developers who haven't yet learned to pay attention to these things who are the ones that bound controls are most attractive to, so the code produced ends up being less than ideal.

Woody Z

Similar Threads
Thread Thread Starter Forum Replies Last Post
Prefer Not To Use Data-Bound Controls... soundchaser59 ASP.NET 2.0 Basics 1 July 9th, 2007 09:13 PM
bound Vs unbound controls on front ends Richard_AU General .NET 2 January 9th, 2007 08:36 PM
Bound Controls cpanson ADO.NET 0 June 24th, 2006 07:29 PM
Accessing bound controls through javascript dungerdanish Classic ASP Professional 0 June 21st, 2005 05:23 AM

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.