[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考

原文:[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考

.NET 分布式架构开发实战之三 数据访问深入一点的思考

　　前言：首先，感谢园子里的朋友对文章的支持，感谢大家，希望本系列的文章能够真正的对大家起到一点帮助的作用。再次感谢大家。

大家也许想问，什么时候出代码，代码一定会出的，我不想一上来就开始抛出一大堆的代码，然后讲解，架构的设计在思考的过程，思考到了，代码也就水到渠成了。

上篇文章讲述在设计之初，Richard所画出的一些草图，本篇对之前的草图做了进一步的思考。

　　本篇的议题如下：

　　1.       草图的一些问题在哪里

　　2.       重审之前项目中数据层的问题

　　3.       思维的一点突破

　　4.       回首再看数据访问层

　　系列文章链接:

[原创].NET 分布式架构开发实战之一 故事起源

[原创].NET 分布式架构开发实战之二 草稿设计

[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考

[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)

[原创].NET 分布式架构开发实战五 Framework改进篇

[原创].NET 业务框架开发实战之六 DAL的重构

[原创].NET 业务框架开发实战之七 业务层初步构想

[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略

[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略

[原创].NET 业务框架开发实战之十 第一阶段总结，深入浅出，水到渠成（前篇）

[原创].NET 业务框架开发实战之十 第一阶段总结，深入浅出，水到渠成（后篇）

　　1.       草图的一些问题在哪里

当Richard把草图画出来了之后，想到了另外的一个问题：在DAL数据层之间提供的那个接口层到底应不应该是Services Interface。其实这个接口层是普通的Interface层还是Services Interface，Richard也拿不定主意的，因为当初之所以要把这个接口层改为Services Interface，是因为在数据源提供者(Service Agent)那块给了他“灵感”——数据源可以使用远程的Services。基于这个思想，所以Richard也考虑到了：也许，现在设计的这个DAL，哪一天会作为服务给其他的程序提供数据也不说定。

虽然，这个问题对现在来说不是那么的重要，但是在Richard的心里，无法说服自己到底使用哪一种接口层(也许是Richard这个人的性格有关吧，一定要给个理由说服自己，但是这个理由又不能随随便便的糊弄自己)。

Richard想到了之前在开发项目的时候，也确实曾经把其他公司提供的服务作为数据源的情况。当时的调用虽然只是进行查询，增加，删除，修改的简单操作，但是很多的流程已经在服务提供者那边定义好了，例如在发送一批货物的时候，Richard只是调用了服务接口的一个CreateProduct(Product product)方法，但是在服务器那端却做了很多的事情：计算库存，生成订单，选择货物供应商等等。这样说来，如果现在Richard把DAL上面加上一个Services Interface层，那么DAL或者其他的层就必须提供很多的逻辑操作，或者不一定是逻辑操作，还可以是数据格式验证、身份验证。

如果真的这样设计，那么数据层的做的事情就很多了，要很多的逻辑。而这些逻辑在BLL中进行才是比较好的选择，想到这里，Richard似乎开始明白：把Services Interface层放在BLL层之上。这样就可以充分的利用BLL的逻辑验证功能。所以DAL之上的接口层，还是决定采用普通的接口。

　　2.       重审之前项目中数据层的问题

Richard在数据层DAL这块花了大量时间来思考，其实是有原因的。在之前的项目中，数据层的设计显得很臃肿，而且在Richard看来，这些代码已经可以用一种比较通用的方式来写，没有必要写那么复杂的代码。

　　例如，在EmployeeDAL中有以下的方法：

代码

        public Employee GetEmployeeById(string employeeId);
        public Emplpyee GetEmployeeByName(string employeName);
        public string GetEmployeePositionById(string employeeId);
        public int GetEmployeeCount();

这样写，没有错。但是有一点引起了Richard的思考：DAL类中，很多的方法基本上都是查询的方法，而Add, Update, Delete在很多的DAL类中形式都比较的统一，特别是在使用了Linq, Entity Framework之后，所有的数据实体类Add，Update, Delete方法几乎是一样的，如在Linq中可以使用DataContext.GetTable<T>().InsertOnSubmit(entity)方法来插入任何的数据实体类。

但是就只有这些不同条件的查询方法很难统一，几乎是每个不同的DAL都要去实现自己的一些特有的查询方法。但是Richard认为把这些方法统一是有可能的，甚至是达到那种“以不变应万变的”效果才好，带着这个想法Richard开始进行很多的尝试。

　　3.       思维的一点突破

Richard极力的在自己的脑海搜寻解决的方案，也翻阅自己之前下载和买过的书籍，看看那些是否与查询数据有关，只要看到有“查询”两个字的章节，Richard就不会放过。也参看了.NET的一个知名开源Framework 的设计思想。

给了他提示的就是Fowler<<企业应用架构模式>>一书，书中提到的查询对象(Query Object)， Richard参看了之后第一反应就是：确实不错，但是太抽象了，没有给出一些示例。

其实之前Richard在看这本书的时候，认为书的高度太高了，Richard几次攻读，都是深受打击。所以，结果是Richard很敬畏这本书，但是还是想有朝一日能够拿下它。现在书中就有了查询对象的一些解决方案和实现，Richard硬着上了。

Richard认为：很多的事情不是等你的所有条件都具备才去做的，事情往往是在你还没有准备好的情况下就已经发生了，凡事都有一个开头，做架构也是这样的，开始设计一个架构的时候，并且不是说明你已经完全的把所有技术都掌握了，完美了，肯定是有一个开始尝试的过程。可能在开始设计的时候，漏洞百出，但是思维的周密性也是这样慢慢的锻炼出来的。

平时在思考的时候，自己站在一个高一点的角度看问题(现在是开发人员，但是开发人员在设计和开发的时候可以这样想：如果我是架构的设计者,我会怎么做？)，思维的高度上去了，机会到来的时候也就从容了。

Richard开始重新理解查询对象。其实查询对象就是在一定程度上隐藏了SQL语句，查询对象是解释器模式的一种应用,实际上查询对象最后还是要解释为SQL语句到数据库中去执行的(不管在中间过程是如何一步步的操作这个查询对象，因为数据库现在只是认识SQL，所以查询对象最终还是要生成SQL语句)。

查询对象主要用途就是使得客户程序可以构造各种的查询，而且查询中使用的都是与业务类有关的属性，这就意味着，客户程序不用了解数据库的表名和列名。这种做法最直接的好处就是业务开发的人员不用知道数据库的构造。

而且如果查询对象的设计是以接口的形式出现，那么灵活性就更加的大。例如，设计一个IQuery的查询对象接口，然后，在架构中有两个实现了IQuery接口的查询对象，如LinqQuery, EFQuery,这两个具体的查询对象最终会被分别解释为Linq和Entity Framework可以识别的语句，再通过Linq和Entity Framework去执行数据操作。在程序中就可以通过配置来决定使用哪种查询对象和使用哪种数据访问技术。

　　越来越多的想法在Richard的脑海中出现，而随之带来的问题也开始堆积。基本的思想是有了，但是实现起来那就得是另外的一回事了。怎么把这些思绪理清，怎么把这些理清的思绪变为代码的实现，这个成为了摆在Richard面前最现实的难题。

　　但是不管怎样，已经有了一点点的进展，记得当初考虑的时候还是头脑一片空白，现在的想法一个接着一个，在思维上进步了。Richard觉得有点欣慰。

　　4.       回首再看数据访问层

有了上面的思考，Richard再次审视了DAL，开始发觉：DAL其实就只是一个存取数据和操作数据的地方，这就是DAL的主要功能。现在数据层的设计基本上已经可以实现了，而且可以做到“以不变应万变”，不管BLL中对数据进行什么样的操作，在DAL层都可以用那个四种增，删，查，改的方法搞定。

　　本篇就到这里，谢谢各位！

　　下篇讲述: .NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁

　　版权为小洋和博客园所有，转载请标明出处给作者。

　　http://www.cnblogs.com/yanyangtian