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

开发者社区> 杰克.陈> 正文

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

简介: 原文:[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考 .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 InterfaceRichard也拿不定主意的,因为当初之所以要把这个接口层改为Services Interface,是因为在数据源提供者(Service Agent)那块给了他“灵感”——数据源可以使用远程的Services。基于这个思想,所以Richard也考虑到了:也许,现在设计的这个DAL,哪一天会作为服务给其他的程序提供数据也不说定。

 

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

 

       Richard想到了之前在开发项目的时候,也确实曾经把其他公司提供的服务作为数据源的情况。当时的调用虽然只是进行查询,增加,删除,修改的简单操作,但是很多的流程已经在服务提供者那边定义好了,例如在发送一批货物的时候,Richard只是调用了服务接口的一个CreateProduct(Product product)方法,但是在服务器那端却做了很多的事情:计算库存,生成订单,选择货物供应商等等。这样说来,如果现在RichardDAL上面加上一个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之后,所有的数据实体类AddUpdate, 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,这两个具体的查询对象最终会被分别解释为LinqEntity Framework可以识别的语句,再通过LinqEntity Framework去执行数据操作。在程序中就可以通过配置来决定使用哪种查询对象和使用哪种数据访问技术。

 

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

 

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

 

  4.       回首再看数据访问层

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

 

  本篇就到这里,谢谢各位!

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

 

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

  http://www.cnblogs.com/yanyangtian

 

 

 

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
我为什么要写:新书《离线和实时大数据开发实战》
新书《离线和实时大数据开发实战》 购买链接(机械工业出版社官方淘宝店铺) 感谢@薛奎 和@空无 大大写推荐书评。 空无和薛奎的书评 大数据技术一直是个领先互联网公司的必备核心技术,阿里巴巴最近10年一直在持续加大投入,并将大数据处理技术用于大量的大规模业务场景。每年双十一对实时、离线技术也都是极限的考验,而作者就是在这样的环境下成长起来,基于真实业务场景钻研相关的技术,既有实战也有
3118 0
【开发课堂】支付宝小程序视图层数据绑定和渲染的能力
1.数据绑定:使用 Mustache 语法(双大括号)将变量包起来,可以作用于各种场合。  a. 作用于内容  {{message}}  Page({ data: {message: 'Hello alipay!'}}) b.
665 0
“分布式事务”的理解(适用于访问多个数据库之间)
        原文地址:http://blog.163.com/soli1988_blog/blog/static/176895272201212812416747/              总体来看,如果所有数据的修改仅依靠单个数据源就能完成,则这个事务就相当简单了。然而,随着商业需求的日益增加,应用程序变得越来越复杂,经常需要访问多个数据库,这些数据库通常分布在不同的地方,这就是
830 0
Android开发6——布局中的wrap_content和fill_parent以及match_parent
  一、言简意赅 fill_parent 是让控件宽或者高占全屏 wrap_content是让控件的高或宽仅仅把控件里的内容包裹住而不是全屏     二、分别来看  1 fill_parent 设置一个构件的布局为fill_parent将强制性地使构件扩展,以填充布局单元内尽可能多的空间。这跟Windows控件的dockstyle属性大体一致。设置一个顶部布局或控件为fil
1069 0
SpringBoot实战(四)之使用JDBC和Spring访问数据库
这里演示的是h2databse示例,所以简单的介绍普及下h2database相关知识 H2数据库是一个开源的关系型数据库。 H2是一个嵌入式数据库引擎,采用java语言编写,不受平台的限制,同时H2提供了一个十分方便的web控制台用于操作和管理数据库内容。
2229 0
Netty4 实战精华EventLoop 和线程模型
简单地说,线程模型指定了操作系统、编程语言、框架或者应用程序的上下文中的线程管理的关键方面。 显而易见地,如何以及何时创建线程将对应用程序代码的执行产生显著的影响,因此开发人员需要理解与不同模型相关的权衡。
1217 0
+关注
杰克.陈
一个安静的程序猿~
10427
文章
2
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载