软件体系结构【4】 MVC体系结构风格、分层风格
2016-10-11 00:23
405 查看
MVC是模型(Model),视图(View)和控制(Controller)的缩写,是一种设计创建 Web 应用程序的模式。
最典型的MVC就是JSP + servlet + javabean的模式。
Model(模型)表示应用程序核心功能与数据(比如数据库记录列表)。
View(视图)负责为用户显示信息(数据库记录)。一个模型可能拥有多个视图。
Controller(控制器)处理输入(写入数据库记录)。
模型的责任
从数据库取出数据,并且赋予数据变量
负责业务逻辑实现
负责数据验证,然后将数据存入数据库
视图的责任
获取用户输入
向controller发送处理请求
接收来自Controller的反馈并将model的处理结果显示给用户
控制器的责任
接收来自客户的请求
调用model业务逻辑方法
调用View显示执行结果
MVC交互示意图
对于数据更新,MVC采用改变-传播机制(change-propagation)
如果用户通过一个view的controller改变了model,所有的view必须反映出该改变。
当数据发生变化的时候,model通知所有的view,告诉他们数据已经改变了;
Views可以遍历model中的数据,以便发现到底是什么改变了。然后更新显示数据。
使用观察者模式的MVC架构类图
使用MVC架构:
1)容易增加或者改变视图。
事务逻辑被封装在Model中,所以在新增加一个视图的时候,不必要改动模型,而是因为业务逻辑都是一样的,所以只需要新增加一个视图类即可。
2) 容易独立地更新每个独立的软件模块
由于一个应用被分离为三个软件模块,因此,我们可以独立地改变其中的一个模块,而不影响其它两个模块。例如,一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
3) 代码易开发易维护
4) 业务逻辑更易测试
-不适合小型,中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失;
-对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率;
-视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用;
-依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
2、分层风格
分层系统采用多个层次组织,每一层必须起且仅起两个作用:
(1)使用下层提供的功能。
(2)为上层提供服务。
最底层通常由硬件连接。
广为人知的分层系统的应用是TCP/IP五层网络模型、操作系统、数据库系统等。
优点:
–支持逐层抽象的系统设计,有利于设计者对一个复杂系统进行分解;
–支持更新,因为每一层至多和相邻的上下层交互,因此功能的改变通常只影响相邻的上下层;
–支持复用,如果某独立层保证了功能的完整性并且提供了文档化的接口,便可在多个语境中复用。一组标准接口也可以使用各种不同的实现方法。
–支持测试。具有定义明确的层接口以及交换层接口的各个实现的能力提高了可测试性。
缺点:
§并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;
§效率的降低:
–由分层风格构成的系统,运行效率往往低于整体结构。
–在上层中的服务如果有很多依赖于最底层,则相关的数据必须通过一些中间层的若干次转化,才能传到;
§很难找到合适的、正确的层次抽象方法:
–层数太少,分层不能完全发挥这种风格的可复用性、可更改性和可移植性上的潜力。
–层数过多,则引入不必要的复杂性和层间隔离冗余以及层间传输开销。
–目前,没有可行的广为人们所认可的层粒度的确定和层任务的分配方法。
照旧一个栗子🌰。这里主要讲解三层架构。
三层架构是近年来经常使用的软件体系结构。该体系结构可以分为通用的3层架构与运行在互联网上的三层架构软件,这里说的是前者。
传统的三层层次体系结构
显示层(Presentation layer):
显示层通常包括用户图形界面,用于用户输入、用户请求与显示用户请求的返回结果等。
显示层调用应用层组件的过程,函数或者方法。但是应用层从来不会调用显示层的功能。
应用层(Application layer):或者称为业务逻辑(Business Logic)层。主要包括应用的业务逻辑,实现了应用的商业功能。
该层的组件封装了应用的核心数据与功能。
在该层中,如果要访问数据库或者要将程序运行中产生的数据存储到数据库,必须调用永久数据存储层的相应的数据库访问方法,而不能直接访问数据库。
永久数据存储层(Permanent Data Storage layer):该层包含数据库的访问与将永久数据存储到数据库中的功能。
在Java实现中,该层包含了利用JDBC写的数据库访问代码。
该层不能调用应用层与显示层,而只能将执行应用层的请求对数据库的访问结果返回给应用层。而应用层有可能将该数据返回给显示层
3、三层层次架构与MVC软件体系结构的比较
在形式上,三层架构类似于MVC 架构,都是由三部分软件模块组成的,但是实际上它们是不同的。
两种架构相似之处如下:
都是由三部分软件模块组成的
三层架构的显示层与MVC架构的View类似;
三层架构的应用层与MVC架构的Model类似。
三层体系结构与MVC体系结构的区别如下:
各个模块之间的调用关系不同:
三层架构的一个根本原则是显示层不能直接越过应用层直接调用永久数据存储层的代码。首先显示层必须调用应用层,然后再由应用层的相关的方法转而调用永久数据存储层。不允许有相反方向的调用。因此,三层架构的交互是线性的;
MVC架构的程序组件之间的交互是三角形的:View对象发送更新给Controller对象,Controller对象更新Model对象,并且View对象直接地从Model对象得到更新。
对数据库的访问方式不同:
三层架构指定一个永久数据访问层,所有对数据库的访问均有此层承担;
MVC架构没有指定专门的数据库访问模块,一般的情况下是由Model直接访问数据库,但是也没有排除Controller中直接访问数据库的可能。
关于控制模块的不同:
MVC架构中存在一个专门的Controller模块;
而层次架构中通常没有这样专门的模块。事实上,很多设计者在层次架构中的应用层里面单独地指定一个类似的控制模块。
使用观察者模式的3层层次架构与MVC架构
值得注意的是,在3层架构中,应用层与表示层之间使用观察者模式必然会导致应用层对显示层的调用(notifyObservers()),这违反了层次架构的原则。但是考虑到采用观察者机制更新图形界面的效率,以上的小小的“违规”也是值得的。
最典型的MVC就是JSP + servlet + javabean的模式。
Model(模型)表示应用程序核心功能与数据(比如数据库记录列表)。
View(视图)负责为用户显示信息(数据库记录)。一个模型可能拥有多个视图。
Controller(控制器)处理输入(写入数据库记录)。
模型的责任
从数据库取出数据,并且赋予数据变量
负责业务逻辑实现
负责数据验证,然后将数据存入数据库
视图的责任
获取用户输入
向controller发送处理请求
接收来自Controller的反馈并将model的处理结果显示给用户
控制器的责任
接收来自客户的请求
调用model业务逻辑方法
调用View显示执行结果
MVC交互示意图
对于数据更新,MVC采用改变-传播机制(change-propagation)
如果用户通过一个view的controller改变了model,所有的view必须反映出该改变。
当数据发生变化的时候,model通知所有的view,告诉他们数据已经改变了;
Views可以遍历model中的数据,以便发现到底是什么改变了。然后更新显示数据。
使用观察者模式的MVC架构类图
使用MVC架构:
1)容易增加或者改变视图。
事务逻辑被封装在Model中,所以在新增加一个视图的时候,不必要改动模型,而是因为业务逻辑都是一样的,所以只需要新增加一个视图类即可。
2) 容易独立地更新每个独立的软件模块
由于一个应用被分离为三个软件模块,因此,我们可以独立地改变其中的一个模块,而不影响其它两个模块。例如,一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
3) 代码易开发易维护
4) 业务逻辑更易测试
-不适合小型,中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失;
-对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率;
-视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用;
-依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
2、分层风格
分层系统采用多个层次组织,每一层必须起且仅起两个作用:
(1)使用下层提供的功能。
(2)为上层提供服务。
最底层通常由硬件连接。
广为人知的分层系统的应用是TCP/IP五层网络模型、操作系统、数据库系统等。
优点:
–支持逐层抽象的系统设计,有利于设计者对一个复杂系统进行分解;
–支持更新,因为每一层至多和相邻的上下层交互,因此功能的改变通常只影响相邻的上下层;
–支持复用,如果某独立层保证了功能的完整性并且提供了文档化的接口,便可在多个语境中复用。一组标准接口也可以使用各种不同的实现方法。
–支持测试。具有定义明确的层接口以及交换层接口的各个实现的能力提高了可测试性。
缺点:
§并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;
§效率的降低:
–由分层风格构成的系统,运行效率往往低于整体结构。
–在上层中的服务如果有很多依赖于最底层,则相关的数据必须通过一些中间层的若干次转化,才能传到;
§很难找到合适的、正确的层次抽象方法:
–层数太少,分层不能完全发挥这种风格的可复用性、可更改性和可移植性上的潜力。
–层数过多,则引入不必要的复杂性和层间隔离冗余以及层间传输开销。
–目前,没有可行的广为人们所认可的层粒度的确定和层任务的分配方法。
照旧一个栗子🌰。这里主要讲解三层架构。
三层架构是近年来经常使用的软件体系结构。该体系结构可以分为通用的3层架构与运行在互联网上的三层架构软件,这里说的是前者。
传统的三层层次体系结构
显示层(Presentation layer):
显示层通常包括用户图形界面,用于用户输入、用户请求与显示用户请求的返回结果等。
显示层调用应用层组件的过程,函数或者方法。但是应用层从来不会调用显示层的功能。
应用层(Application layer):或者称为业务逻辑(Business Logic)层。主要包括应用的业务逻辑,实现了应用的商业功能。
该层的组件封装了应用的核心数据与功能。
在该层中,如果要访问数据库或者要将程序运行中产生的数据存储到数据库,必须调用永久数据存储层的相应的数据库访问方法,而不能直接访问数据库。
永久数据存储层(Permanent Data Storage layer):该层包含数据库的访问与将永久数据存储到数据库中的功能。
在Java实现中,该层包含了利用JDBC写的数据库访问代码。
该层不能调用应用层与显示层,而只能将执行应用层的请求对数据库的访问结果返回给应用层。而应用层有可能将该数据返回给显示层
3、三层层次架构与MVC软件体系结构的比较
在形式上,三层架构类似于MVC 架构,都是由三部分软件模块组成的,但是实际上它们是不同的。
两种架构相似之处如下:
都是由三部分软件模块组成的
三层架构的显示层与MVC架构的View类似;
三层架构的应用层与MVC架构的Model类似。
三层体系结构与MVC体系结构的区别如下:
各个模块之间的调用关系不同:
三层架构的一个根本原则是显示层不能直接越过应用层直接调用永久数据存储层的代码。首先显示层必须调用应用层,然后再由应用层的相关的方法转而调用永久数据存储层。不允许有相反方向的调用。因此,三层架构的交互是线性的;
MVC架构的程序组件之间的交互是三角形的:View对象发送更新给Controller对象,Controller对象更新Model对象,并且View对象直接地从Model对象得到更新。
对数据库的访问方式不同:
三层架构指定一个永久数据访问层,所有对数据库的访问均有此层承担;
MVC架构没有指定专门的数据库访问模块,一般的情况下是由Model直接访问数据库,但是也没有排除Controller中直接访问数据库的可能。
关于控制模块的不同:
MVC架构中存在一个专门的Controller模块;
而层次架构中通常没有这样专门的模块。事实上,很多设计者在层次架构中的应用层里面单独地指定一个类似的控制模块。
使用观察者模式的3层层次架构与MVC架构
值得注意的是,在3层架构中,应用层与表示层之间使用观察者模式必然会导致应用层对显示层的调用(notifyObservers()),这违反了层次架构的原则。但是考虑到采用观察者机制更新图形界面的效率,以上的小小的“违规”也是值得的。
相关文章推荐
- 总结:我喜欢的软件体系结构——分层、模块化与OSGi
- 软件体系结构的风格(转载)
- 谈论软件体系结构的风格
- 经典软件体系结构风格(三)
- 软件体系结构:二维分层、模块化和开放平台
- 软件结构体系和风格
- 分布式软件体系结构风格(C/S,B/S)
- 经典软件体系结构风格(二)
- 软件体系结构第三章-解释器风格
- 3.1软件体系结构风格
- 软件体系结构风格
- 软件体系结构风格
- [笔记]软件体系结构(2)--分层
- 经典软件体系结构风格(四)
- 软件体系结构的风格
- 软件体系结构风格---基于事件的隐式调用
- 软件体系结构风格
- 软件体系结构:二维分层、模块化和开放平台
- 经典软件体系结构风格(五)
- 软件体系结构:二维分层、模块化和开放平台