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.