初始mvc模式

初始mvc模式

在最近学习jdbc,以及mybatis时，网上文档的代码实例大多遵循一个规范，就是在包的命名方面都会出现以下几个类型：dao , controller,service, dao 四个层级；在小生几经谷歌搜索之下。终究是略知一二，原来那不就是大名鼎鼎的mvc 开发模式吗！写此博客，以记录自己的思考

---

引入

在我们最初学习写程序项目时，都会有几个功能：

• 用户交互的菜单界面
• 具体业务逻辑实现
• 对数据源的访问，以及更新数据

这三个功能都是可以放在一起实现·的，这听起来多方便啊，但实际上这样的代码模式非常糟糕！不仅代码显得很臃肿，而且在项目后期的维护以及技术迭代显得异常艰难。于是乎，便出现一种分层模式 ：按照上面列出的几个基本功能 将代码分为 model（模型层），view（视图层），controller (控制层)，下图是我对几个层级的理解：

（如有不当之处：各位大牛们勿喷 哈哈）

在这里插入图片描述

dao层

Dao层：主要是做数据持久层的工作，负责与数据库进行联络的一些任务都封装在此，DAO层的设计首先是设计DAO的接口，然后就可以在service中调用此接口来进行数据业务的处理，而不用关心此接口的具体实现类是哪个类，显得结构非常清晰。

就比如你要实现学生成绩的 CRUD：

• 设计dao接口

package dao;
public interface dao{
    /**
    **/
    void deleteStudent(String name); // 根据学生姓名删除学生
    void assStudent(Student);
    void updateStudent(Student);
    void selecStudent();   
}

• 实现dao接口 ：将传进来的参数来写sql语句（代码繁多，就不再展示）

总之一句话；dao层的各种方法设计只是与数据库打交道的，基本上都为crud ,而很少考虑与其他层的交互

service层

当然也就是我们的业务逻辑层，存放业务逻辑处理，也是一些关于数据库处理的操作，但不是直接和数据库打交道，他有接口还有接口的实现方法；但最重要的是：它必须调用dao层的方法

何为业务逻辑？就拿学生成绩系统来看：所谓的业务，我就指出一二：在***add***学生时，你该判断该学生是否存在与数据库，如果有，则不应该掉用***dao***的方法，并且输出：”该学生已存在“；否则调用dao的方法，将学生数据写入数据库

controller层

Controller层：主要功能是处理用户的请求，即通过用户传过来的参数，根据参数调用对应service的方法

这样讲还是有点晦涩，附上一张图

这样关系就一目了然，代码写起来也是顺啊！反正各层的代码调用顺序：

View>Controller>Service>Dao

在mvc的模式下，业务逻辑层和数据访问层要遵循面型接口编程的。这种接口定义和具体实现逻辑的分开，对于后期功能改进，删除非常爽，因为每个层级都是互不影响！

c的模式下，业务逻辑层和数据访问层要遵循面型接口编程的。这种接口定义和具体实现逻辑的分开，对于后期功能改进，删除非常爽，因为每个层级都是互不影响！