08-MVC&JavaBean

MVC 设计模式

MVC 模式（Model-View-Controller）是软件工程中的一种软件架构模式，把软件系统分为 3 个基本部分：模型（Model）、视图（View）和控制器（Controller）。

MVC 可对程序的后期维护和扩展提供了方便，并且使程序某些部分的重用提供了方便。而且 MVC 也使程序简化，更加直观。

• 控制器 Controller：对请求进行处理，负责请求转发
• 视图 View：界面设计人员进行图形界面设计
• 模型 Model：程序编写程序应用的功能（实现算法等等）、数据库管理；

注意，MVC 不是 Java 的东西，几乎现在所有 B/S 结构的软件都采用了 MVC 设计模式。

JavaWeb 与 MVC

Model 1

version-1

JSP Model1 是 JavaWeb 早期的模型，它适合小型 Web 项目，开发成本低！Model 1 第一代时期，服务器端只有 JSP 页面，所有的操作都在 JSP 页面中，连访问数据库的 API 也在 JSP 页面中完成。也就是说，所有的东西都耦合在一起，对后期的维护和扩展极为不利。

version-2

JSP Model1 第二代有所改进，把业务逻辑的内容放到了 JavaBean 中，而 JSP 页面负责显示以及请求调度的工作。虽然第二代比第一代好了些，但还让 JSP 做了过多的工作，JSP 中把视图工作和请求调度（控制器）的工作耦合在一起了。

Model 2

JSP Model2 模式已经可以清晰的看到 MVC 完整的结构了。

• JSP：视图层，用来与用户打交道。负责接收用来的数据，以及显示数据给用户
• Servlet：控制层，负责找到合适的模型对象来处理业务逻辑，转发到合适的视图
• JavaBean：模型层，完成具体的业务工作，例如：开启、转账等。

注意，在 Service 层中不能出现 JavaWeb API，例如 request、response 等。也就是说，Service 层代码是可重用的，甚至可以应用到非 Web 环境中。业务层的每个方法可以理解成一个万能，例如转账业务方法。Service 层依赖 Dao 层，而 Web 层依赖 Service 层！

MVC 与 三层架构

摘自：https://www.jianshu.com/p/71ae09665214

简述

在软件开发中，MVC 与三层架构这两个专业词汇经常耳闻，同时总有很多人将它们混为一谈，认为三层架构就是指 MVC，给它画上等号，但实际上，这是错误的认知，并不是说它们没有任何关系，而是 MVC 与三层架构不是简单的相等。下面将拿 JavaWeb 开发中的 MVC（SSM框架）与三层架构进行比较，让大家理清两者之间的关系。

概念

系统架构

所谓系统架构是指整个应用系统程序大的结构，常见的系统架构有三层架构与MVC。前面已经说了，三层架构与 MVC 不是简单的相等，它们存在差别，但又联系。现在可以肯定的是，这两种系统架构的出现，都是为了降低系统模块间的耦合度。

三层架构

三层架构是指：视图层 View、服务层 Service、持久层 Dao，分别完成不同的功能。

• View 层：用于接收用户提交请求的代码在这里编写
• Service 层：系统的业务逻辑主要在这里编写
• Dao 层：直接操作数据库的代码在这里编写

为了更好的降低各层间的耦合度，在三层架构程序设计中，采用面向抽象编程。即上层对下层的调用，是通过接口实现的。而下层对上层的真正服务提供者，是下层接口的实现类。服务标准（接口）是相同的，服务提供者（实现类）可以更换。这就实现了层间耦合的降低。

MVC

MVC 是指：Model 模型、View 视图、Controller 控件器。

• View：视图，为用户提供使用界面，与用户直接进行交互
• Model：模型，承载数据，并对用户提交请求进行计算的模块。其分为两类，一类称为数据承载 Bean，一类称为业务处理 Bean
  • 所谓数据承载 Bean 是指实体类，专门承载业务数据的，如 Student、User 等
  • 而业务处理 Bean 则是指 Service 或 Dao 对象，专门用于处理用户提交请求的
• Controller：控制器，用于将用户请求转发给相应的 Model 进行处理，并处理 Model 的计算结果向用户提供相应响应

MVC 架构程序的工作流程是这样的：

1. 用户通过 View 页面向服务端提出请求，可以是表单请求、超链接请求、AJAX 请求等
2. 服务端 Controller 控制器接收到请求后对请求进行解析，找到相应的 Model 对用户请求进行处理
3. Model 处理后，将处理结果再交给 Controller
4. Controller 在接到处理结果后，根据处理结果找到要作为向客户端发回的响应 View 页面。页面经渲染（数据填充）后，再发送给客户端。

关系

MVC 与三层架构的关系

MVC 与三层架构很相似，但它们并不一样。如果以三层架构为背景，那么 MVC 的三个部分分别对应的是什么？

• 三层架构中的 View 层简单的说就是跟用户发生直接关系的层，MVC 中的 V 和 C 就是这样的存在，所以 MVC 中的 V 和 C 均属于三层架构的 View 层。
• 同时，我们知道 MVC 中的M（Model）包括了数据承载 Bean 和业务处理 Bean，其中业务处理 Bean 分为 Service 或 Dao 对象，分别对应业务逻辑处理和数据库操作，相应的，它们对应的是三层架构中的 Service 层和 Dao 层。
• 故，它们的关系如下图所示：
  

SSM 与 三层架构的关系

SSM 即 SpringMVC、Spring、Mybatis 三个框架。它们在三层架构中所处的位置是不同的，即它们在三层架构中的功能各不相同，各司其职。

• SpringMVC：作为 View 层的实现者，完成用户的请求接收功能。SpringMVC 的 Controller 作为整个应用的控制器，完成用户请求的转发及对用户的响应。
• MyBatis：作为 Dao 层的实现者，完成对数据库的 CRUD 功能。
• Spring：以整个应用大管家的身份出现。整个应用中所有的 Bean 的生命周期行为，均由 Spring 来管理。即整个应用中所有对象的创建、初始化、销毁，及对象间关联关系的维护，均由 Spring 进行管理。

JavaBean

• JavaBean 是一个遵循特定写法的 Java 类，它通常具有如下特点：
  • 这个 Java 类必须具有一个无参的构造函数
  • 属性必须私有化
  • 私有化的属性必须通过 public 类型的方法暴露给其它程序，并且方法的命名也必须遵守一定的命名规范
• JavaBean 在开发中，通常用于封装数据，对于遵循以上写法的 JavaBean 组件，其它程序可以通过反射技术实例化 JavaBean 对象，并且通过反射那些遵守命名规范的方法，从而获知 JavaBean 的属性，进而调用其属性保存数据。
• JavaBean 的属性
  • JavaBean的属性可以是任意类型，并且一个 JavaBean 可以有多个属性。每个属性通常都需要具有相应的 setter、 getter 方法，setter 方法称为属性修改器，getter 方法称为属性访问器。
  • 属性修改器必须以小写的 set 前缀开始，后跟属性名，且属性名的第一个字母要改为大写，例如， name 属性的修改器名称为 setName，password 属性的修改器名称为 setPassword。
  • 属性访问器通常以小写的 get 前缀开始，后跟属性名，且属性名的第一个字母也要改为大写，例如，name 属性的访问器名称为 getName，password 属性的访问器名称为 getPassword。
  • 一个 JavaBean 的某个属性也可以只有 set 方法或 get 方法，这样的属性通常也称之为只写、只读属性。
• JavaBean 要实现 Serializable<I>
  

软件分层

• 为什么要分层？
  • 使软件具有结构性，便于开发、维护和管理
  • 将不同功能模块独立，在需要替换某一模块时不需要改动其他模块，方便代码的复用、替换
• 层与层的耦合
  • 在分层结构中，我们希望将各个功能约束在各自的模块（层）当中的，而当属于某一层的对象、方法“入侵”到了其他层，如将 web 层的 ServletContext 对象传入 service 层，或 service 层调用 Dao 独有的方法，就会导致层与层之间的关系过于“紧密”，当需要修改某一层时不可避免的要修改其他关联的层，这和我们软件分层最初的设想 —— 层与层分离，一个层尽量不依赖其他层存在，当修改一层时无需修改另一层的设想是违背的。
  • 这种“入侵”造成的“紧密”关系就早做层与层之间发生的“耦合”，而去掉这种耦合性的过程就叫做层与层之间“解耦”。利用工厂类可以实现解耦的功能
• 如何判断一项功能属于哪一层？
  • 此项功能在业务逻辑上更贴近与哪一层,放在哪一层更能较少耦合
  • 此项功能是否必须使用某一层特有的对象
  • 如果放在哪一层都可以，那么放在哪一层更方便技术上的实现，及方便代码的编写和维护

config.properties

CustService=cn.edu.nuist.service.impl.CustServiceImpl
CustDao=cn.edu.nuist.dao.impl.CustDaoImpl

BasicFactory

public class BasicFactory {
    private BasicFactory() {}
    private static BasicFactory factory = new BasicFactory();
    private static Properties prop = null;

    static {
        prop = new Properties();
        try {
        prop.load(new FileReader(BasicFactory.class.getClassLoader()
                .getResource("config.properties").getPath()));
        } catch (Exception e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }

    public static BasicFactory getFactory() {
        return factory;
    }

    // 使用泛型实现层与层之间的解耦
    public <T> T getInstance(Class<T> clazz) {
        String cName = clazz.getSimpleName();
        String cImplName = prop.getProperty(cName);
        try {
            return (T) Class.forName(cImplName).newInstance();
        } catch (Exception e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }
}

异常的处理

• 如果一个异常抛给上一层会增加程序的耦合性，请当场解决:如将 XML 解析错误抛给 service 层，那么当换成 MySQLDAO 时，还需要修改 service 去掉 XML 解析异常的处理
• 如果上一层明确需要此异常进行代码的流转，请抛出：如当查找一个用户信息而用户找不到时，可以抛出一个用户找不到异常，明确要求上一层处理
• 如果这一层和上一层都能解决尽量在这一层解决掉
• 如果这一层不能解决，而上一层能解决抛给上一层
• 如果所有层都不能解决，则应抛出给虚拟机使线程停止，但是如果直接抛出这个异常，则还需要调用者一级一级继续往上抛出最后才能抛给虚拟机，所以还不如在出现异常的位置直接 try-catch 住后转换为 RuntimeException 抛出。如：读取配置文件出错，任何层都不能解决，转为 RuntimeException 抛出，停止线程