前言：

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

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

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

　　本篇的议题如下：

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

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

　　3、思维的一点突破

　　4、回首再看数据访问层

　　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();        

        

        
        
      
        
NET技术：.NET 分布式架构开发实战之三 数据访问深入一点的思考，转载需保留来源！
        
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。