关于数据访问的思考

一直都在想怎样简化数据访问的方式,怎么快速的完成数据访问层的建立，是通过采用传说中的ORM之类的，还是自己建立一个自己想法的数据访问方式，我想数据访问层的建立大至分为两类：

通过ADO.NET对象直接建立DAL像PETSHOP中一样；
通过采用ORM直接去掉数据访问层或采用一些半自动的ORM对象来完成数据访问；

两种方式应当说各自都有自己的优势和不足，采用采用建立DAL层可以得到快速的数据访问性能，充分发挥各种数据库的优势来建立，并且所有代码通过自己来编写所以比较好控制，有什么问题也比较容易解决，起点低。

而通过采用ORM呢，能够有效的减少数据访问的代码编写量，将需要解决的软件问题集中到解决业务的问题上来，减少开发时间和开发周期，并且能够直接就具备针对多种数据库的访问能力。

两者各自己的优势正是另一方的不足，采用建立DAL层需要编写大量的代码，针对不同的数据库需要编写不同的DAL，通过采用CodeSmith等工具可以减少部分代码的编写，但如果前其数据库设计不足那么修改数据库的结构就很容易需要重要编写想应的代码，就这一点也是一个需要解决的问题啊，特别是现在敏捷开发的流行，怎么能够像瀑布模型一样将什么问题都想好呢。而采用ORM呢学习周期长，特别是SQL发发展超过30年针对各种问题的解决都有自己的办法，而全自动的ORM都发明有自己的XQL之类的语言，与SQL想比发展不超过10年，在特殊问题面前怎么能够与SQL相比呢，如果使用半自动的ORM能够解决这个问题，但那全需要自己编写的SQL又是一个大的问题，与DAL想比又没有那么大的优势了。而我解决问题的基础理念就是采用最简单的办法解决问题。啊，让我真是不知道怎么选择啊。

通过分析我想能够通过采用一种方式既能够有效的解决DAL中的问题，又能够解决ORM中的问题呢。特别是需要与.NET的WCF，WF，ObjectDataSource等相互协作使用，最大限度的减少数据访问的复杂度，减少对于常规则CRUD的数据访问。

思来想去，终于想到了一个办法，通过对以往项目的数据访问分析研究，发现数据访问的90%以上的访问都有相同的模式，CRUD是其中最多的操作，特别是CUD基本是都是相同的模式，相邻的SQL，而对于Read的种类最多，其中根据主键进行的访问最多，基本上第个DomainModel对象都有，而对于根据一个DomainModel的属性进行的访问也很多，特别是当一个DomainModel的对象中的那一个属性不能够相同时，基本上都需要能够根据这个属性来查看对象，有时还分根据这个属性来查找满足要求的一组对象。在管理DomainModel或是向用户展示DomainModel中最多的则是能够多个属性值来进行查找，它们之间操作最多的AND操作，就是相互并起来查找结果，有时候其中一个值会是另一张表中的其中一个属性的值。这些情况，当然还有其它的情况，但特别的少，很多小的项目可能根本就没有。

啊，思考想去，如果能够将这些个常规的数据访问能够像ORM一样解决，而针对那很少的一部分操作能够采用一种机制来解决，我想定能将数据访问的操作简单化。

当前特别还需要注意的是WCF中的DataContract对于DomainModel的影响等问题，如果能够将这些都了解好，我想建立一种快速的数据访问方式应当是不难度的。

啊，还得再想想。