MVC+ADO模式
浏览数：57 /
时间：2015年06月09日
MVC+DAO设计模式
本文摘自：http://www.paper.edu.cn 基于MVC+DAO设计模式的Struts框架应用 鲍嘉鑫
在Model层，如果数据源发生改变，必然导致不同的数据访问，JavaBean也必然被修改以寻找新的数据源。执行业务逻辑时，真实主题的实现是不相同的，但在实现真实主题前后必然会有相同或者重复执行的步骤和过程，造成代码重复。而且在Servlet中，如果直接调用真实主题实现类，必然带来很强的耦合性，不易于维护。
针对以上问题，产生了基于MVC模式Model层的DAO模式(Data Access Object)，主要由工厂类(Factory)、代理类(Proxy)、实现类(DAOImpl)、DAO接口和值对象类(VO)以及数据库连接类组成。
（1）Factory类：用来实例化所操作的对象。
（2）Proxy类：代替真实主题实现类完成所有工作，使得真实主题实现类可以专心完成真实主题，而准备工作和收尾工作全部由代理类完成。
（3）DAOlmpl类：完成数据访问真实主题的业务逻辑处理，得到最终用户所希望获得的数据信息。
（4）DAO接口：定义所需要的具体操作方法。
（5）VO类：封装数据库表，1个vo类代表一张表，1个vo类对象代表表中的1条记录。通过该对象的属性和相应的setter方法和getter方法来对应设置或得到数据库表中的字段。
（6）DBConnection类：专门用于连接数据库，可根据不同的数据源和持久性数据存储修改类的属性，减少了主题实现类的工作。MVC+DAO模式，将业务逻辑处理功能进一步细分，虽然前期开发代码量有所增加，但在大中型项目中的优势还是很明的，将业务对象和数据实现彻底分离，可移植性和可维护性大大增强，简化了业务模块，提高了系统整体可读性和开发效率。当然，这种设计模式也仍然存在DAO对象和SQL语句嵌套和耦合的缺陷。
本文摘自：http://www.paper.edu.cn 基于MVC+DAO设计模式的Struts框架应用 鲍嘉鑫
在Model层，如果数据源发生改变，必然导致不同的数据访问，JavaBean也必然被修改以寻找新的数据源。执行业务逻辑时，真实主题的实现是不相同的，但在实现真实主题前后必然会有相同或者重复执行的步骤和过程，造成代码重复。而且在Servlet中，如果直接调用真实主题实现类，必然带来很强的耦合性，不易于维护。
针对以上问题，产生了基于MVC模式Model层的DAO模式(Data Access Object)，主要由工厂类(Factory)、代理类(Proxy)、实现类(DAOImpl)、DAO接口和值对象类(VO)以及数据库连接类组成。
（1）Factory类：用来实例化所操作的对象。
（2）Proxy类：代替真实主题实现类完成所有工作，使得真实主题实现类可以专心完成真实主题，而准备工作和收尾工作全部由代理类完成。
（3）DAOlmpl类：完成数据访问真实主题的业务逻辑处理，得到最终用户所希望获得的数据信息。
（4）DAO接口：定义所需要的具体操作方法。
（5）VO类：封装数据库表，1个vo类代表一张表，1个vo类对象代表表中的1条记录。通过该对象的属性和相应的setter方法和getter方法来对应设置或得到数据库表中的字段。
（6）DBConnection类：专门用于连接数据库，可根据不同的数据源和持久性数据存储修改类的属性，减少了主题实现类的工作。MVC+DAO模式，将业务逻辑处理功能进一步细分，虽然前期开发代码量有所增加，但在大中型项目中的优势还是很明的，将业务对象和数据实现彻底分离，可移植性和可维护性大大增强，简化了业务模块，提高了系统整体可读性和开发效率。当然，这种设计模式也仍然存在DAO对象和SQL语句嵌套和耦合的缺陷。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
