![74_74.gif](/Emoticons/74_74.gif)
这是编程吗?一切都显得不够从容。
第一次玩C#时,数据适配器让我眼前一亮,可是转而一想,这个东东的除了用来Select,好像就干不了什么了。
虽然,一次Select能够自动生成Update、Delete、Insert的我SQL语句,但还是心烦。因为它们只针对单表。
更可恶的是,居然给人一种绝对不能更新视图的感觉。
研究来,研究去,发现一个道理:在数据库设计关系,不如跑到DataSet中设计关系,一张表让它有多大就多大,尽量的大吧,这样,用一堆适配器,从表中生成大量的DataSet中的表,然后设个关系,用起来,也其乐融融。
可惜,这样的方法,绝对不适合与大中型的应用程序,不对,准确地说,小型的都有点吃力了
![71_71.gif](/Emoticons/71_71.gif)
![77_77.gif](/Emoticons/77_77.gif)
还有什么好办法没有?
又想了想,结果又得到一个诡异的方法,就是:数据库中设好关系,分割好表后,用视图将它们组合起来。
编程时,采用一个数据适配器进行Select这个视图,生成一个DataSet,然后再弄几个数据适配器专门针对合成这张视图的子表进行非Select的操作,然后,在数据更新时,采用这几个专门更新数据用的适配器进行Update这个DataSet,也可以达到更新的效果。
这样做,比上面的方法要好一些,但是,感觉上,还是白白耗费了大量的数据传输。
不行了,行不通了。
但是,这个
![cry_smile.gif](/Emoticons/cry_smile.gif)
应该,还有什么办法吧?
看看,嗯,针对数据适配器,自己写更新的语句吧。
哦,不行,何苦呢,要是这样做,我不如直接用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中,实在是,不敢多说了)。
目前我想到一个开源的工程,正在筹备中,过段时间看看,有机会就发起一下。
基本上就是一个能够直接生成数据访问层的代码的配置器,能够让系统快速地生成操作代码,要不,写程序,太累。