为什么编程会那么麻烦？.net中数据库的操作是否有高效编程的方式？
使用.net开发WinForm程序时，总是有一时郁闷
这是编程吗？一切都显得不够从容。
第一次玩C#时，数据适配器让我眼前一亮，可是转而一想，这个东东的除了用来Select，好像就干不了什么了。
虽然，一次Select能够自动生成Update、Delete、Insert的我SQL语句，但还是心烦。因为它们只针对单表。
更可恶的是，居然给人一种绝对不能更新视图的感觉。
研究来，研究去，发现一个道理：在数据库设计关系，不如跑到DataSet中设计关系，一张表让它有多大就多大，尽量的大吧，这样，用一堆适配器，从表中生成大量的DataSet中的表，然后设个关系，用起来，也其乐融融。
可惜，这样的方法，绝对不适合与大中型的应用程序，不对，准确地说，小型的都有点吃力了
，因为这在极端的情况下，等于弄了一个数据库到内存中来
，天知道，xml格式的数据流在内存中，要干掉多少空间。一个几十K的程序，能够占个几十M的内存，估计也是前无古人，后无来者了吧？
还有什么好办法没有？
又想了想，结果又得到一个诡异的方法，就是：数据库中设好关系，分割好表后，用视图将它们组合起来。
编程时，采用一个数据适配器进行Select这个视图，生成一个DataSet，然后再弄几个数据适配器专门针对合成这张视图的子表进行非Select的操作，然后，在数据更新时，采用这几个专门更新数据用的适配器进行Update这个DataSet，也可以达到更新的效果。
这样做，比上面的方法要好一些，但是，感觉上，还是白白耗费了大量的数据传输。
不行了，行不通了。
但是，这个
，在小型程序上，可以将就用了，至少，这种方式没有影响到原始数据库中的关系，。
应该，还有什么办法吧？
看看，嗯，针对数据适配器，自己写更新的语句吧。
哦，不行，何苦呢，要是这样做，我不如直接用sql语句更新数据库，还要来得直观一些，不但效率高，实际上也就比数据适配器的编写多个connection的open和close方法的调用。
想过来，想过去，突然觉得，还是不用数据适配器喽，干脆直接用DataReader来读数据，用DataSet只起数据呈现的作用算了.....
郁闷哦。
到底微软老大，搞清楚推出的这个什么DataSet有什么用没有哦，用了那么久的.net的，除了微软自己一直吼这个东西好，就没看见还有人跟着吼它好的，微软也幽默，MSDN中居然明确指出，有时候一些操作还是必须得用ADO的，这是不是意思是ADO.NET和ADO只是两种不同的数据访问模型而已？
这个DataSet在玩实时数据更新应该上如何体现？还有，对于一些紧要的数据，应该是有多快能存入数据库，就要多快能存入数据库，以防丢失，但这里，我觉得，一停电 ，什么都完蛋了。
DataSet到底应该用来干啥？
ADO.NET好歹也是比ADO多个.NET吧，怎么感觉上，用起来就那么郁闷哦。
一直以为ADO.NET是新的数据访问模型，比ADO更优秀，现在看来，晕。听说下一版中又有一些变化，我的天，微软还想干什么？
各位XDJM，能不能给予一些高效编程的指导？我忍无可忍了，想起最早的VB中的数据环境，就有一些环境，那个东东，是多么地可爱啊。
我的高效编程的定义就是：一两分种完成数据库的访问的定义，最理想的状态是：尽量不写代码的的情况下完成所有操作(数据适配器的Fill和Update，有时候感觉是在恶心人，Web程序还可以理解，但WinForm中，实在是，不敢多说了)。
目前我想到一个开源的工程，正在筹备中，过段时间看看，有机会就发起一下。
基本上就是一个能够直接生成数据访问层的代码的配置器，能够让系统快速地生成操作代码，要不，写程序，太累。
这是编程吗？一切都显得不够从容。
第一次玩C#时，数据适配器让我眼前一亮，可是转而一想，这个东东的除了用来Select，好像就干不了什么了。
虽然，一次Select能够自动生成Update、Delete、Insert的我SQL语句，但还是心烦。因为它们只针对单表。
更可恶的是，居然给人一种绝对不能更新视图的感觉。
研究来，研究去，发现一个道理：在数据库设计关系，不如跑到DataSet中设计关系，一张表让它有多大就多大，尽量的大吧，这样，用一堆适配器，从表中生成大量的DataSet中的表，然后设个关系，用起来，也其乐融融。
可惜，这样的方法，绝对不适合与大中型的应用程序，不对，准确地说，小型的都有点吃力了
，因为这在极端的情况下，等于弄了一个数据库到内存中来，天知道，xml格式的数据流在内存中，要干掉多少空间。一个几十K的程序，能够占个几十M的内存，估计也是前无古人，后无来者了吧？还有什么好办法没有？
又想了想，结果又得到一个诡异的方法，就是：数据库中设好关系，分割好表后，用视图将它们组合起来。
编程时，采用一个数据适配器进行Select这个视图，生成一个DataSet，然后再弄几个数据适配器专门针对合成这张视图的子表进行非Select的操作，然后，在数据更新时，采用这几个专门更新数据用的适配器进行Update这个DataSet，也可以达到更新的效果。
这样做，比上面的方法要好一些，但是，感觉上，还是白白耗费了大量的数据传输。
不行了，行不通了。
但是，这个
，在小型程序上，可以将就用了，至少，这种方式没有影响到原始数据库中的关系，。应该，还有什么办法吧？
看看，嗯，针对数据适配器，自己写更新的语句吧。
哦，不行，何苦呢，要是这样做，我不如直接用sql语句更新数据库，还要来得直观一些，不但效率高，实际上也就比数据适配器的编写多个connection的open和close方法的调用。
想过来，想过去，突然觉得，还是不用数据适配器喽，干脆直接用DataReader来读数据，用DataSet只起数据呈现的作用算了.....
郁闷哦。
到底微软老大，搞清楚推出的这个什么DataSet有什么用没有哦，用了那么久的.net的，除了微软自己一直吼这个东西好，就没看见还有人跟着吼它好的，微软也幽默，MSDN中居然明确指出，有时候一些操作还是必须得用ADO的，这是不是意思是ADO.NET和ADO只是两种不同的数据访问模型而已？
这个DataSet在玩实时数据更新应该上如何体现？还有，对于一些紧要的数据，应该是有多快能存入数据库，就要多快能存入数据库，以防丢失，但这里，我觉得，一停电 ，什么都完蛋了。
DataSet到底应该用来干啥？
ADO.NET好歹也是比ADO多个.NET吧，怎么感觉上，用起来就那么郁闷哦。
一直以为ADO.NET是新的数据访问模型，比ADO更优秀，现在看来，晕。听说下一版中又有一些变化，我的天，微软还想干什么？
各位XDJM，能不能给予一些高效编程的指导？我忍无可忍了，想起最早的VB中的数据环境，就有一些环境，那个东东，是多么地可爱啊。
我的高效编程的定义就是：一两分种完成数据库的访问的定义，最理想的状态是：尽量不写代码的的情况下完成所有操作(数据适配器的Fill和Update，有时候感觉是在恶心人，Web程序还可以理解，但WinForm中，实在是，不敢多说了)。
目前我想到一个开源的工程，正在筹备中，过段时间看看，有机会就发起一下。
基本上就是一个能够直接生成数据访问层的代码的配置器，能够让系统快速地生成操作代码，要不，写程序，太累。
