MVC的设计模式在JavaWeb中的实现
2014-05-20 21:17
274 查看
JSP开发模式
jsp开发模式的发展
1.模式1:(适合小型项目的技术的开发)
a.第一版本,纯jsp(封装数据,处理数据,显示数据)
b.第二版本,Jsp+JavaBean.
jsp:收集数据,显示数据
JavaBean:封装、处理
2.模式2:servlet+Jsp+JavaBean(是mvc在java中的具体的实现,是java技术实现的具体的内容)
a.servlet:负责协调jsp和javabean,获得数据,处理数据(业务逻辑),封装到javabean中,选择jsp去显示数据。
b.jsp:显示
c.JavaBean:封装和简单处理
思想:业务处理与显示数据相分离。
软件设计模式
1.MVC软件设计模式(和java无关)
是一种分离业务逻辑和显示界面的设计方法。
M:model模型
V:view视图
C:Controller控制器
2.对于javaweb开发的mvc模式:
servlet(controller)+jsp(view)+javabean(model)
那么经典的三册架构的体系图如下:
达到这种经典的三层架构以后,javaweb的架构已经很不错了,但是从软件工程角度分析,上述架构还是存在问题。
那么看一下上述架构的使用。
在中心的黄色部分:也就是服务端部分,层与层之间的调用关系。
举一个例子:
web层:UserServlet.java类
service层:UserService类
dao层:UserDao类
javaBean:user
那么层与层之间的调用关系就该是这样:
在UserServlet.java中调用UserService。
那么调用的方式只能是在UserServlet类中去创建UserService的对象。
如下:
class UserServlet{
UserServcie userService=new UserService();
//调用userService的相关方法进行业务逻辑的操作
。。。。
}
同理:UserService调用UserDao的时候,也有类似上述的代码。
有上述的分析得出结论1:
1.那么上述代码之间的层与层之间的关系就很紧密。
是违背了软件工程的设计思想的。
软件工程要求,模块与模块之间的耦合式越低越好。一句经典的软件工程设计的话是这样的。
“高内聚,低耦合”。
同时上述的dao层,我们看一下既有对xml的操作,也有对db的操作,甚至还有更多。得出了结论2:
2.上述架构,同时违背了“高内聚,低耦合”中的高内聚的思想。
于是上面的架构体系又有了如下的增进:
对于上述的架构图进行分析:
看service层,dao层
1.解决dao层的内聚问题,把xmlDao和dbDao进行分离。
2.对dao层抽取一个共性的接口出来。Dao接口
分析:之前的架构中,service层调用dao层是这样的。
UserService中需要写这样的代码:XmlDao xmlDao=new XmlDao()//此时没有接口
加上接口以后,Dao dao=new XmlDao();
3.添加工厂
上面的写法变成:Dao dao=Factory.getXmlDao();
那么工厂如何调用dao层的相关方法呢?如果直接调用,出现的结果是虽然解决了service层和dao层之间的耦合关系,但是其实只不过演变
成了工厂和dao层之间的高耦合。
那么加入了xml技术,工厂通过读取xml文件,然后利用java的反射,去创建所需创建的对象就ok了。
而在xml中只要提供了类的全路径,然后做相关配置,目的是方便工厂去读取xml文件去创建对象。
4.添加配置文件。
配置文件仅仅是字符串,和dao层之间没有耦合关系。
总结:对于第三种架构(高内聚,低耦合),便于维护,便于扩展。
为什么便于扩展,举个例子:比如,dao层中,又有了新的持久化技术,service层实际上无所知道不知道,只要修改配置文件。工厂就会去有
相应的操作。这样一来,是不是便于维护和扩展。
上面了,我们看了service层,dao层,通过接口,工厂类,配置文件的方式实现了解耦。
同理,web层,service层也可以通过相同的方式的进行解耦。在上图中没有完全体现。
随着技术的发展,出现了很多mvc的框架比如struts+spring+hibernate/springMvc.
在刚出现这些框架的时候,基本上都是通过上述方式进行解耦。用过框架的人都知道,框架多基于配置文件,反射原理,内省等。
再发展了如今,搞架构的那些人,觉得,写配置文件也很费劲,就有了如今的基于注解模式的框架设计。
但是,上述的架构思想,和演变过程,是后期框架技术的源头哦。
后期,我也会对JavaWeb项目开发过程的框架技术结合MVC设计模式做更深入的分析。通常javaweb+框架技术的开发,被人们称
作java企业级开发。也就比较的流行的J2EE/JAVAEE.
补充:在javaweb项目的基于MVC软件设计模式,一般会进行如下分包结构:
使用分包描述结构
com.ghsy ,公司域名倒写(安徽安庆高恒塑业有限责任公司)
com.ghsy.项目名称
com.ghsy.项目名称.dao
dao接口
com.ghsy.项目名称.dao.impl
dao实现类
com.ghsy.项目名称.service
service接口
com.ghsy.项目名称.service.impl
service实现类
com.ghsy.项目名称.web.servlet
servlet处理类
com.ghsy.项目名称.web.filter
过滤器处理类
com.ghsy.项目名称.web.listener
监听器处理类
com.ghsy.项目名称.domain
javabean 封装数据(bean)
com.ghsy.项目名称.utils
工具类
com.ghsy.项目名称.exception
自定义异常
com.ghsy.项目名称.constant
java常量 Xxx.NAME
/WEB-INF/ jsp页面,安全
* 使用请求转发显示jsp页面
jsp开发模式的发展
1.模式1:(适合小型项目的技术的开发)
a.第一版本,纯jsp(封装数据,处理数据,显示数据)
b.第二版本,Jsp+JavaBean.
jsp:收集数据,显示数据
JavaBean:封装、处理
2.模式2:servlet+Jsp+JavaBean(是mvc在java中的具体的实现,是java技术实现的具体的内容)
a.servlet:负责协调jsp和javabean,获得数据,处理数据(业务逻辑),封装到javabean中,选择jsp去显示数据。
b.jsp:显示
c.JavaBean:封装和简单处理
思想:业务处理与显示数据相分离。
软件设计模式
1.MVC软件设计模式(和java无关)
是一种分离业务逻辑和显示界面的设计方法。
M:model模型
V:view视图
C:Controller控制器
2.对于javaweb开发的mvc模式:
servlet(controller)+jsp(view)+javabean(model)
那么经典的三册架构的体系图如下:
达到这种经典的三层架构以后,javaweb的架构已经很不错了,但是从软件工程角度分析,上述架构还是存在问题。
那么看一下上述架构的使用。
在中心的黄色部分:也就是服务端部分,层与层之间的调用关系。
举一个例子:
web层:UserServlet.java类
service层:UserService类
dao层:UserDao类
javaBean:user
那么层与层之间的调用关系就该是这样:
在UserServlet.java中调用UserService。
那么调用的方式只能是在UserServlet类中去创建UserService的对象。
如下:
class UserServlet{
UserServcie userService=new UserService();
//调用userService的相关方法进行业务逻辑的操作
。。。。
}
同理:UserService调用UserDao的时候,也有类似上述的代码。
有上述的分析得出结论1:
1.那么上述代码之间的层与层之间的关系就很紧密。
是违背了软件工程的设计思想的。
软件工程要求,模块与模块之间的耦合式越低越好。一句经典的软件工程设计的话是这样的。
“高内聚,低耦合”。
同时上述的dao层,我们看一下既有对xml的操作,也有对db的操作,甚至还有更多。得出了结论2:
2.上述架构,同时违背了“高内聚,低耦合”中的高内聚的思想。
于是上面的架构体系又有了如下的增进:
对于上述的架构图进行分析:
看service层,dao层
1.解决dao层的内聚问题,把xmlDao和dbDao进行分离。
2.对dao层抽取一个共性的接口出来。Dao接口
分析:之前的架构中,service层调用dao层是这样的。
UserService中需要写这样的代码:XmlDao xmlDao=new XmlDao()//此时没有接口
加上接口以后,Dao dao=new XmlDao();
3.添加工厂
上面的写法变成:Dao dao=Factory.getXmlDao();
那么工厂如何调用dao层的相关方法呢?如果直接调用,出现的结果是虽然解决了service层和dao层之间的耦合关系,但是其实只不过演变
成了工厂和dao层之间的高耦合。
那么加入了xml技术,工厂通过读取xml文件,然后利用java的反射,去创建所需创建的对象就ok了。
而在xml中只要提供了类的全路径,然后做相关配置,目的是方便工厂去读取xml文件去创建对象。
4.添加配置文件。
配置文件仅仅是字符串,和dao层之间没有耦合关系。
总结:对于第三种架构(高内聚,低耦合),便于维护,便于扩展。
为什么便于扩展,举个例子:比如,dao层中,又有了新的持久化技术,service层实际上无所知道不知道,只要修改配置文件。工厂就会去有
相应的操作。这样一来,是不是便于维护和扩展。
上面了,我们看了service层,dao层,通过接口,工厂类,配置文件的方式实现了解耦。
同理,web层,service层也可以通过相同的方式的进行解耦。在上图中没有完全体现。
随着技术的发展,出现了很多mvc的框架比如struts+spring+hibernate/springMvc.
在刚出现这些框架的时候,基本上都是通过上述方式进行解耦。用过框架的人都知道,框架多基于配置文件,反射原理,内省等。
再发展了如今,搞架构的那些人,觉得,写配置文件也很费劲,就有了如今的基于注解模式的框架设计。
但是,上述的架构思想,和演变过程,是后期框架技术的源头哦。
后期,我也会对JavaWeb项目开发过程的框架技术结合MVC设计模式做更深入的分析。通常javaweb+框架技术的开发,被人们称
作java企业级开发。也就比较的流行的J2EE/JAVAEE.
补充:在javaweb项目的基于MVC软件设计模式,一般会进行如下分包结构:
使用分包描述结构
com.ghsy ,公司域名倒写(安徽安庆高恒塑业有限责任公司)
com.ghsy.项目名称
com.ghsy.项目名称.dao
dao接口
com.ghsy.项目名称.dao.impl
dao实现类
com.ghsy.项目名称.service
service接口
com.ghsy.项目名称.service.impl
service实现类
com.ghsy.项目名称.web.servlet
servlet处理类
com.ghsy.项目名称.web.filter
过滤器处理类
com.ghsy.项目名称.web.listener
监听器处理类
com.ghsy.项目名称.domain
javabean 封装数据(bean)
com.ghsy.项目名称.utils
工具类
com.ghsy.项目名称.exception
自定义异常
com.ghsy.项目名称.constant
java常量 Xxx.NAME
/WEB-INF/ jsp页面,安全
* 使用请求转发显示jsp页面
相关文章推荐
- MVC的设计模式在JavaWeb中的实现
- 用例子说明MVC 设计模式(以Objective-C 实现)
- MVC与设计模式的关系及MVC的实现原理和设计原理
- MVC设计中DAO模式实现的目标
- 为什么MVC不是一种设计模式? ---比较Backbone和Ext4.x在MVC实现上的差异
- 用例子说明MVC 设计模式(以Objective-C 实现)
- 对MVC的理解?为什么要用MVC?在Cocoa中MVC是怎么实现的?你还熟悉其他的OC设计模式或别的设计模式吗
- 学习笔记_Java_day12_设计模式MVC(13).JavaWeb的三层框架(14)
- 设计模式MVC(PHP实现一)
- Objective-C设计模式(MVC)的实现,以及协议与委托的运用
- 用例子说明MVC 设计模式(以Objective-C 实现)
- javaWeb入门<1>Servlet+Jsp+JavaBean实现MVC开发模式登陆注册实例详解
- 为什么MVC不是一种设计模式? ---比较Backbone和Ext4.x在MVC实现上的差异
- 用例子说明MVC 设计模式(以Objective-C 实现)
- [Java][Web]Request 实现转发和 MVC 设计模式
- AspectJ实现设计模式(六)—单例模式
- 设计模式之C#实现(一)--AbstractFactory
- 实现Prototype设计模式
- Prototype设计模式的实现
- 设计模式之C#实现(一)--AbstractFactory