摘要:我们讨论过Entity类,和封装过的Dataset,关于为什么用Entity,一个原因就是希望可以通过编译器来检查我们的一些错误。
前面讲到的代码自动生成工具,实际上只是帮助你完成了一些代码,软件的结构没有改善使用代码自动生成工具,并不符合我们前面提到的原则——让强大的计算机来代替迟钝的你,来做本该由他来做的事情(让正确的人按照正确的方法作正确的事)因为既然可以用代码自动生成工具生成这么多有规律的代码,那么就应该可以将这项功能内嵌的你的代码里使用代码自动生成工具,并不符合我们前面提到的无重复原则和抽象化原则,相同的事情应该通过一个抽象出来的统一的gateway来做
不希望包罗万象,不期望可以处理任何复杂的逻辑
对于xml文件方式和attribute方式,倾向于attribute,不是因为它是新技术,而是因为,我一直希望,代码是可以自描述的,xml之所以这么强大,其中一个因素就是xml是可以自描述的。我们希望代码可以讲述他自己的故事,可以告诉调用者怎么样来使用他
attribute的应用也越来越广泛,比如asp.Net的数据验证,也有一些文章讲attribute对某些传统设计模式的影响,attribute会催生一些新的模式
而且,访问xml或者访问attribute有一个单独的类来实现,其具体实现的改变不影响程序其他部分
将Entity持久化时, 不需要对Entity数据做验证,如果有错误,直接抛出异常,验证的工作交给别的对象来做
对于动态sql和存储过程,不要求统一,什么方便就用什么,简单的,有规律的就用sql,复杂的用view或者存储过程来封装,实际上拼sql访问table和自动生成参数访问存储过程是类似的,存储过程可以也可以看作datasource
效率不是最主要的,一个程序员一个月的工资可以买很多东西,而且清晰的结构使我们容易的找出真正的瓶颈,加以优化
基本原型
DataHelper.SaveEntity(CustomerEntity.GetType(), id)DataHelper.DeleteEntity(CustomerEntity.GetType(), id)DataHelper.UpdateEntity(CustomerEntity.GetType(), id)
DataHelper根据BookEntity的Type到xml里面找到Node,也可以通过反射访问CustomerEntity的attribute
可以用动态sql,也可以用存储过程
对于Query的话,可以Qualifications q = new Qualifications()q.add( new Qualification( Query.Like, CustomerEntity.GetType(), customerName ) )CustomerEntitys[] = DataHelper.GetEntityList(CustomerEntity.GetType(), q)
接下来
缓存?把Dataset转化成Entity的数组或者集合 ?讲EntityList绑定到UI Control ?Entity类要承担哪些责任...[
阅读全文]