Thought Persistence

一个很小的 WINFORM 程序，涉及到 CRUD，一次写入(批量更新)，存储过程交互，数据比较，数据缓存，麻雀虽小，倒也五脏俱全，于是懒得去找那些.Net下的ORM了，省得去代码生成，属性配置，既然ADO.Net2.0已经提供了 QueryBuilder，Typed DataSet，DataBinding，那就直接上吧!

拖，拉，配，拖，拉，配.......

开始很机械的操作，一番云里来雨里去之后，功能是完成了，但就我所体会到的 ADO.Net 2.0 有以下感觉：

优点：

1、性能
据说性能比1.0有巨大提升, 反正我感觉还是挺快的，即使在配置较差的电脑上，另外，使用Sql Profier监测自己软件的SQL还是很重要的， 这样你能更清楚的知道 DataSet 何时提交，提交了什么样的 SQL

2、内存数据操作
这个真是非常好的一个特性，配合 GRID ，可以很好地实现一次写入，也就是可以 Undo 了，不怕误操作再来数据的错误，而且后期的设定 PK ，再用 FIND 方法定位，给两个数据集之间进行比对提供了极大的便利。 此处，可以凭空创建一个 DataTable， 任意改变其中的 Columns, Constrains， 这对于数据处理而言， 意思非常巨大， Table 的行集操作能力结合.Net语言的其它超强处理能力，真的有一种农奴翻身做主人的感觉，因为现在数据完全是可控的了

3、Query Builder
一些既不算简单又不复杂的 SQL 可以写在这里，省却了代码中直接写入的换行+ @ 标识，又没必要搞得 DB 中 SP 漫天飞舞(貌似MS本身特别钟爱在 SQL SERVER 中用超多的 SP，好像在向大家说：量再多也不怕!)，不管如何，我觉得这是很好地把 SQL 和 CODE 分离的一个举措，所以除了 DataSet 中，其它地方我都不会出现 SQL，如果需要写SQL，那么找相关的 DataSet 去 Add Query 就是了

4、版本控制
因为更新时它使用的是set ... = newValue where field = oldValue的方法 所以如果其它人在你修改时改动了数据， 它会报冲突错误的， 当然，好的方法还是自己通过timestamp来控制

5、Typed
总算可以打点了，将就一点吧，能用就行了

缺点：

1、命名空间混乱
生成的 Typed DataSet 和所对应的 Adpater 居然不在同一个空间下，这可给调用时增加了很多的痛苦， using 这个 using 那个， 就觉得这哥俩是强扭的瓜一般

2、SP支持不够
我有一个SP返回的是一个 temp table，结果在 DataSet 设计时，死活只能让我返回 int ，拜托让我自己决定返回一个 DataSet 总行吧， 可是人家原则性很强， 不让你乱来，最后，我只好把它生成的部分代码 Copy 了一份自己起了炉灶新建了个类， 把调用和返回部分改了， 让它返回一个 DataSet

3、Null 处理非常糟糕
还得 IsXXXNull() 这样来判断是否为Null, 直接访问就给弹错, string 类型的也照弹不误， .Net 2.0不是有了nullable type了么， 不知它为什么不用， 难道是为了性能？ 这个地方真是让我头大

4、约束
这本来是个好事， 比如说某列必须不允许为空， 防止错误的数据， 但是， 但是我有时候只是想用这个 typed datarow 来 trasfer data， 可是这个约束就是不让你通过， 所以 DataSet 中的 DataRow 无法很好地用来做数据传递

5、连接字符串
好像只能放appconfig或直接写死，而且你还不能跑 Designer.cs 中去改， 改了还得给你恢复回来，此处还有CommandTimeOut等属性的设计，在设计期都没有支持，对于自动生成的代码， 我是不敢去改动它的， 下次设计时它又会把我的给覆盖掉，上面SP就是一个例子， 为什么就不可以提供额外的控制呢， 比如说通过事件来获取外部的设置

6、可设计带来的不良后果
这点纯属找茬，因为设计带来的代码自动生成让人搞不清到底是如何一回事， 如果我需要去不依赖于 Form 去创建一个全局的 Typed DataSet 用，就得颇费一番周折了