软件体系结构【4】 MVC体系结构风格、分层风格 - HoneyCat

软件体系结构【4】 MVC体系结构风格、分层风格

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五层网络模型、操作系统、数据库系统等。

优点：

–支持逐层抽象的系统设计，有利于设计者对一个复杂系统进行分解；

–支持更新，因为每一层至多和相邻的上下层交互，因此功能的改变通常只影响相邻的上下层；

–支持复用，如果某独立层保证了功能的完整性并且提供了文档化的接口，便可在多个语境中复用。一组标准接口也可以使用各种不同的实现方法。

–支持测试。具有定义明确的层接口以及交换层接口的各个实现的能力提高了可测试性。

缺点：

§并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

§效率的降低：

–由分层风格构成的系统，运行效率往往低于整体结构。

–在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；

§很难找到合适的、正确的层次抽象方法：

–层数太少，分层不能完全发挥这种风格的可复用性、可更改性和可移植性上的潜力。

–层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销。

–目前，没有可行的广为人们所认可的层粒度的确定和层任务的分配方法。

 

照旧一个栗子