p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   ADO.NET (http://p2p.wrox.com/forumdisplay.php?f=109)
-   -   Bound Vs Unbound controls (http://p2p.wrox.com/showthread.php?t=52180)

Richard_AU January 3rd, 2007 09:04 AM

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?


woodyz January 16th, 2007 01:40 PM

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

All times are GMT -4. The time now is 09:11 PM.

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