数据层应该分为两个部分，这样可以更好的“分工”，各自研究自己的功能

 

     数据层应该分为两个部分（并不是说一定要变成两层）第一个部分是处理SQL语句，包括存储过程的名称，存储过程的参数（一下的SQL语句都包含存储过程名称和存储过程的参数）；第二部分是传递SQL语句的。

     我们先说第二部分，这个最典型的就是SQLhelp。他的职责就是接收SQL语句，然后通过ADO.net传递给数据库，如果是select语句的话，需要返回记录集，记录可以放在DataTable里面，也可以用DataReader。但是放不放在实体类里面不是第二个部分的职责。

     有一些tx（包括我在内）会写自己的help，自己写的自己用这舒服嘛，基本功能大概也就是我上面说的这些。

     这个部分还以一个职责，那就是要支持多种数据库！不过这个也不难，在ADO.net2.0的支持下，也是很简单的。

     第一部分就是处理SQL语句的部分，比如我要添加一条新闻，那么就要有这样一条类似的语句

“insert into News (NewsTitle,NewsContent) values (@NewsTitle,@NewsContent) ”。

     那么这样的sql语句是如何获得的呢？这个就是第二部分要处理的事情。

     这里的变化就有很多了。可以自己手写，可以拼接，可以使用LinQ 、Hibernate等，当然有些也直接把第二部分包含进去了。

     相信有好多人就是这么做的，但是也会有些人把这两个部分完全混合在一起了。LinQ 、Hibernate这一类的不知道内部是如何处理的，相信也会由一个明确的区分吧。

     分成两个部分的好处就是可以进一步的“优化”（这个词不太准确，没想到太好的词语）。第二部分很容易就做成通用的，这样就大大的减少了代码量，和发开时间，出现bug的概率也会大大降低。

     第一部分就可以只考虑如何处理SQL语句了，比如不同的数据库的情况下，如何写sql语句。比如在添加、修改的情况下如何处理sql语句，insert into ...... 是不是所有的数据库都支持。尽量让一种sql语句可以“适合”多种数据库。

     如果都支持的话，那么添加数据的情况我是不是只需要写一种SQL语句就可以了，一种SQL语句就可以应对多种数据库。因为这样的话，添加数据的部分我就不必要先定义一个接口，然后在SQL Server 实现一遍接口，Orcale再实现一遍接口，Access再实现一遍接口了。sql语句都是一样的呀（对于添加来说都是insert into ），这样代码量就有节省了一大块。

     同理，修改数据（Update）、删除数据（delete）是不是也可以同样处理呢？

     剩下来的就是最麻烦的分页了。其实这个也简单，快上班了，先不写了。

     对了，还有一些地方，统计报表了、导出数据了、其他一时没先到的地方，这些是不是都可以使用类似的思路来处理一下呢？如果可行的话，那么代码量会减少70%（和petshop相比）。