软件系统架构中的分层思想

关于分层结构
服务器君一共花费了299.662 ms进行了6次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

众所周知,经典的三层结构包括数据访问层、业务逻辑层和表示层。当然,如果继续扩展下去,还可以分为4层、5层……

我相信很多人都用过,很多人都写过,但是为什么要这么做,还是有一部分人是不能够说清楚的,这不是我猜想的,而是遇见过很多想分层但是分的乱七八糟的层次结构。

1. 数据访问层:

功能描述:处理与数据库之间的交互,不应对数据做任何业务上的加工。捕获数据库交互式出现的异常,抛出或记录下来。

说明:它的作用就是数据访问,如果你没有用其他的类似于ORM的框架,那么这里应该是SQL语句集合地(或者你可以把SQL语句写在存储过程中),业务逻辑层和表示层绝对不能出现SQL语句(包括SQL的关键字,单引号、百分号、LIKE等都不能出现)。那么如何组合动态SQL语句呢?这应该是最大的一个问题。我见过很多系统在业务逻辑层定义相当多的型参,然后在表示层收集参数数据,传入业务逻辑层后拼合SQL语句,最后传入数据访问层执行操作,分层的概念已经完全没有意义了。如何解决这个问题呢?最早的强类型数据集、自定义的业务实体,LINQ,或者ORM都可以解决,当然了,这只是他们的一部分功能(其实,我不太愿意用类似于NHibernate的HQL或LINQ)

2. 数据接口层:

功能描述:提供数据访问层的接口标准、以便于提供多数据库的支持,即数据库的随意迁移。

这里我要提一下数据接口层,我见过有很多项目组在数据访问层的上面加了一个数据接口层,然后数据访问层是各个数据接口层的具体实现,但是在业务逻辑层实例化数据层的时候,仍然是实例化到具体的类对象。

IDal_MyClass dalmyclass = new DAL_SQLClass();

我不知道为什么要这么做,除了增加了工作量,其他的一点意义也没有。

那么到底需不需要这么数据接口层呢?我认为在做一个支持多数据库的系统(做产品会多见一些,比如一个CRM系统即可支持SQL Server,也支持Oracle和MySql)时就要用到数据接口层了,当然,单单一个数据接口层完成不了这个任务,你还要为每一种数据库单独做他们自己的数据访问层,并且使用工厂模式以及依赖注入(比如Castle)技术就可以实现多数据库的支持了,你可以在产品安装或者运行时随便进行数据库间的迁移。

3. 业务逻辑层:

功能描述:接受从表示层传过来的数据,做业务上的数据校验,并实现业务流程,最后,把加工后的数据传给数据访问层。

你可以认为在三层之间有两堵墙,三层之间谁也看不见谁,我只做好我的本职工作,其他的事情我不关心。业务逻辑层应该是设计者最关注的地方,也是设计模式应用最广泛的地方,业务逻辑层设计的关键就是尽量的实现松耦合,如果业务逻辑层中的各个类之间都有调用关系,那这就是一个很糟糕的设计。进一步来说,如果把这些松耦合的功能模块的接口作为一种服务的模式(比如Web Service)发布出去,OK,这就是SOA。

4. 业务外观层:

功能描述:把松散的业务逻辑层内的各个细分功能在这里整合,而后作为一个子系统的统一接口发布出去。这也是设计模式的一种。

业务外观层应该是对业务逻辑层的进一步封装。这只有在业务逻辑功能十分繁多但彼此间又有联系的时候才会有用。我刚才说过了,业务逻辑层尽量要实现松耦合,但是各个业务之间肯定是有联系的啊,这种联系起来的工作就要交给业务外观层。要把有联系的几个业务逻辑组合为一个子系统,然后在业务外观层中实现这种联系并发布出去。

我见过很多项目有业务外观层,但业务外观层的方法仅仅是对业务逻辑层一个方法的封装。这样做除了增加工作量,没有任何好处,还不如直接调用业务逻辑层。

5. 表示层:

功能描述:从用户控件中取得数据或者从业务逻辑层取得数据后展现出来,不应对取得的数据做任何加工。

在这层要是出现SQL语句那就更不应该了。在WEB项目中,因为效率的原因,很多时候要在客户端做一些必填项的验证(其实这也是业务逻辑的一部分),但这是值得的。

知其然,还要知其所以然,分层是有好处的,程序的结构很清晰,便于除错、便于扩展、也便于阅读。

本文地址:http://www.nowamagic.net/librarys/veda/detail/1706,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1706

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《敏捷软件开发(原则模式与实践)》 马丁 (作者), 邓辉 (译者)

《敏捷软件开发:原则模式与实践》由享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。1.讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目;2.使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程;3.包含了极具价值的可多次使用的C++和JAVA源代码;4.重点讲述了如何使用UML和设计模式解决面向客户系统的问题。

更多计算机宝库...