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

[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考 .NET ? 　　前言：首先，感谢园子里的朋友对文章的支持，感谢大家，希望本系列的文章能够真正的对大家起到一点帮助的作用。再次感谢大家。 ? 大家也许想问，什么时候出代码，代码一定会出的，我不想一上来就开始抛出一大堆的代码，然后讲解，架构的设计在思考的过程，思考到了，代码也就水到渠成了。 ? 上篇文章讲述在设计之初，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(); ? 这样写，没有错。但是有一点引起了Richard的思考：DAL类中，很多的方法基本上都是查询的方法，而Add, Update, Delete在很多的DAL类中形式都比较的统一，特别是在使用了Linq, Entity Framework之后，所有的数据实体类Add，Update, Delete方法几乎是一样的，如在Linq中可以使用DataContext.GetTableT().InsertOnSubmit(entity)方法来插入任何的数据实体类。 ? 但是就只有这些不同条件的查询方法很难统一，几乎是每个不同的DAL都要去实现自己的一些特有的查询方法。但是Richard认为把这些方法统一是有可能的，甚至是达到那种“以不变应万变的”效果才好，带着这个想法Richard开始进行很多的尝试。 ? 　　3.?????? Richard极力的在自己的脑海搜寻解决的方案，也翻阅自己之前下载和买过的书籍，看看那些是否与查询数据有关，只要看到有“查询”两个字的章节，Richard就不会放过。也参看了.NET的一个知名开源Fra