.NET 分布式架构开发实战之三

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

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

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

　　本篇的议题如下：

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

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

　　3. 思维的一点突破

　　4. 回首再看数据访问层

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

代码

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层都可以用那个四种增，删，查，改的方法搞定。

　　http://www.cnblogs.com/yanyangtian