The drag and drop stuff paints you into a box. Whether that box is good or
bad depends on your application, your coding style and standards, etc.
In 2005, you have TableAdapters. They work very similar to many of the code
gen products out there. Unfortuantely, they do not automagically set up
multi-table DataSets to auto-update. It could be done, based on
dependencies, but you will have to control this ... for now. Useful in
Enterprise Architecture? Sure, why not?
As for getting the data layer out of the UI, I am not sure what you mean. If
you mean the "all in one" objects in .NET 2.0, I agree with you. Can them.
If, instead, you are setting up your layers and using drag and drop, there
is no problem. The DataSets are set up as components, which allows you to
add to UI. The TableAdapeter makes things easier in some respects and harder
in others. I am not sure I am completely shot in the butt with them, but you
can still create bindable components no matter how you are filling the
DataSets.
In short
1. There is nothing wrong with DataSets
2. THere is nothing wrong with drag and drop, but you should understand what
is going on underneath the hood
3. I personally detest the "all in one" data objects. Your mileage may vary.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************************************************
Think outside of the box!
*************************************************