前言:在开发的时候我们常常讨论有关设计模式方面的东西,也学习了不少设计模式,而且也可以写出设计模式的一些演示的代码,但是在真正开发的时候,有时却显得很无能为力,而且觉得用不用都差不多,就算是勉强的用了,也不见得把代码改善了多少。
用不用设计模式,很多时候不是我们说了算的,因为很多的设计,在我们上面的一些人员就已经敲定了的,程序员一般都只是开发一个小小的模块而已,但是即便如此,在我们有限的范围内,我们还是可以有一些发挥的!下面我们就来谈谈一些开发方面的东西!下面来看看从分层到模式的的自然的过渡!
首先看看数据访问层。
数据访问层(Data Access Layer,后面简称DAL),一般是对数据库执行查询,更新,插入和删除操作的代码,是最接近数据库的代码,它必须了解数据库的所有的细节,如表结构,字段名称,存储过程等。在以前我们开发的小小的程序中,经常的做法就是双击按钮进入事件,开始写数据操作代码,当然这样的程序大家现在不会写了,原因很简单,最直观的的原因就是以后代码不好改,到处找SQL的链接操作语句等。说的专业一点就是数据层和业务层,UI层杂糅在一起,职责不清。所以我们就要分开这些,所以就开始有分层的思想了,但是怎么分,可能我们刚开始不是很清楚,也知道设计模式可以解决,但是如果我们立马向设计模式奔,有点唐突:思想可能还没有那么快的过渡。但是,起码我们知道:分,肯定是有好处的。
下面就看看“分”的好处:
1.开发用户界面的人很开发数据访问代码的很多的时候不是同一个人。用户界面开发人员可以忽略与数据库相关的大部分的内容,但是他还是能够为数据库提供用户界面的,因为他起码知道最后数据在界面的表现的效果的。
2.一些获取数据的查询语句会被不通的页面使用,如果直接放入,如aspx页面中,以后的修改可想而知,如果把这些数据操作的代码放到一个地方,如一个专门的数据操作模块中,别的优点先不说,起码以后改起来方面。
3.将数据操作代码硬编码在页面中,以后移植新的数据库,如从SQL SERVER 到DB2,不方便。
下面看看过渡的思路。
现在我们起码知道已经把数据操作代码放到单独的地方。但是需求多变,代码也要应对变化,所以,对于数据操作代码而言,要考虑一下以后的数据库的更改。初步的思维就是判断:把现有的数据库的访问代码都写一份,然后用if---else,没有错,只是很累,开发起码难度也不好说。万一客户说他不喜欢数据库,而是喜欢用别的数据存储方式存储数据,如XML,以前的代码的if---else中要加一段了。我们都不乐意。
要寻求别的方法了,大家知道继承可以来抵御变化,那么就开发一个抽象类,使得我们现在的程序调用这个抽象类,真正做事的是他的子类。把我们的程序比成一个人,他要吃东西,一会吃这,一会吃那,烦!我们就把餐票给他,先哄着他,等真正吃的时候,就用餐票换吃的。
上面我们谈的是给抽象类,其实接口也行,但是我们的数据操作很多都有一定的共性的,就是可以重用一些代码的,那么我们就抽象类最好了。
那么我们的设计就如下图了:
现在的代码设计就好了一点。其实这就是在实现一种设计模式,一般说是策略模式,微软中也称provider提供程序模型设计模式(如MemberShip等就是这样的)。
现在我们的代码起码可以访问很多的数据库了,但是还是有问题:我们从页面接受的数据要验证,要经过一定的处理(专业的说法就是业务逻辑处理过程)才能放入数据库。现在我们可以把也写验证等代码写到DAL中,或者也不写在DAL,哪里需要就哪里写。如果是前者,在DAL中确实是可以放入一些验证等代码,如果全部放,但是这样岂不又和之前的那种代码一样啦!如果是选择后一种,问题很前面的一样了:到处放置,修改起码到处跑!所以,我们有要用一个专门的类或者模块来封装业务处理!这样三层结构就出现了。一种自然的思考,模式的自然使用。
现在结构如下:
现在改分离的是分离了,但是似乎BBL层和DAL合作还是有点问题!确实!
因为我们一般都是看到的下面的三层结构图:
不急,因为我们说了:模式到架构的自然过渡,现在还没有到那一步,因为要真正的把上面的图用我们自然的理解来完成,也就是说,不是硬是用架构来套,框,然后我们就给告诉自己:哦,那就是三层架构,其实这理解是不够的。等到我们谈论下一个话题:DataSet和自定义实体就可以了!
谢谢大家!