三层架构之如何分层

在上篇博客<三层之常用返回值>中,我层提到过关于我在学习三层的遇到的问题,其中对于返回值的问题,我更加我经验,总结了一下.今天我想说的是关于如何分层的问题.

我们知道,无论做什么事情,都需要有指导思想才能完成,分层也是.分层到底要遵循哪些原则呢,我们就来一一看看:

一..逐层调用原则及单向调用原则:

我们就以三层为例子,我们分为U层,B层,D层,其中对D,B,U层分别进行编号1,2,3,其中层的编号越大,就越是处于上层,

那么,我们设计的架构就应该满足以下两个原则:

1.第3层(即U层)只能依赖第2层(即B层),则不可以依赖第1层.

2.如果B层依赖D层,那么B层的编号一定大于D层.

其中第一个原则保证了依赖的逐层性,以及整个架构依赖是逐层向下的,而不能跨层依赖,第二个原则保证了依赖的单向性,即只能上层依赖底层,而不能底层反过来依赖上层!.

二.依赖倒置原则(DIP)

在学习大话设计模式的时候,我们学习过依赖倒置原则,要在三层学习的之前先学习设计模式 ,起作用为后面的学习打基础!

其中依赖倒置原则的具体内容是:

A.高层模块不应该依赖低层模块,两个都应该依赖抽象

B.抽象不应该依赖细节,细节应该依赖抽象!

具体依赖--如果B层中有一个或一个以上的地方要实例化D层的某个具体的类,则说B层具体依赖于D层.(就如机房收费系统中使用了纯三层进行的设计)

抽象依赖--如果B层没有实例化D层的具体类,而是在一个或一个以上的地方实例化了D层的某个接口,则说B层抽象依赖于D层,(就如机房收费系统加了抽象工厂+反射,B层直接盗用接口,D层实现接口)

三.开放--封闭原则

开放--封闭原则定义为:对扩展开放,对修改封闭

在三层中可以这样来描述: 当D层有了一个新的具体实现是,它应该可以在不修改B层的情况下,与B层无缝连接,顺利交互!

四.单一职责原则

单一职责原则定义为:就一个类而言,应该仅有一个引起它变化的原因.

在分层结构里面,可以这样理解,任何一个类都应该有单一的职责,属于单独的一层,而不能同时担负两种职责或属于多层

五.封装变化原则

封装变化的原则定义为:找出应用中可能需要变化之处和重复使用的代码,把它们独立出来,

在机房收费系统中,因为连接数据库我们会在D层每个类中都用到,这是我们就把连接数据处理数据这部分单独出来,封装起来,当D层使用的时候,直接调用封装好的数据连接,这样就增加的了代码的复用性,提高效率了.

有了思想,就是关于怎么分层的问题,在三层中,我们把系统分成了U层,B层,D层,U层主要是跟界面打交道,B层处理业务,D层跟数据库打交道,但是分层就没有一个很明确的界限,有些逻辑判断的东西同样也会出现在U层和D层,比如:

U层出现的逻辑判断:

 '判断输入的卡号是否为数字
        If Not IsNumeric(txtStudentCardID.Text) Then
            MsgBox("输入的卡号为数字,如'123'")
            txtStudentCardID.Text = ""
            txtStudentCardID.Focus()
            Exit Sub
        End If

D层的逻辑判断:

 '返回行数,
        If int < 0 Then
            Return True
        Else
            Return False
        End If

以上的这些都是属于逻辑判断的,但是她们同样出现在了U层和D层,

还有关于对数据库操作的,它也同样出现在U层

U层:

For i = 0 To table.Rows.Count - 1
            cmbUserName.Items.Add(table.Rows(i).Item("UserName"))
            cmdRealName.Items.Add(table.Rows(i).Item("Name"))
        Next

所以综上所述,分层的目的主要是增强代码的复用性,可维护性,,可扩展性,灵活性,提高效率,具体的怎么分层,在遵循分层原则的前提下,还是需要根据自己的需要进行分层!除了把业务逻辑放在B层，其他的逻辑判断可以根据自己的需求放在其他层！

系统分层就是教会我们学习要学会变通!