Springline开发框架手册.docx
- 文档编号:11708661
- 上传时间:2023-06-02
- 格式:DOCX
- 页数:44
- 大小:742.71KB
Springline开发框架手册.docx
《Springline开发框架手册.docx》由会员分享,可在线阅读,更多相关《Springline开发框架手册.docx(44页珍藏版)》请在冰点文库上搜索。
Springline开发框架手册
1.前言
1.1.Web开发技术发展回顾
图:
动态Web编程技术的发展历史
随着Internet技术的广泛使用,Web技术已经广泛应用于Internet上,但早期的Web应用全部是静态的HTML页面,用于将一些文本信息呈现给浏览者,但这些信息是固定写在HTML页面里的,该页面不具备与用户交互的能力,没有动态显示的功能。
很自然地,人们希望Web应用里应该包含一些能动态执行的页面,最早的CGI(通用网关接口)技术满足了该要求,CGI技术使得Web应用可以与客户端浏览器交互,不再需要使用静态的HTML页面。
CGI技术可以从数据库读取信息,将这些信息呈现给用户;还可以获取用户的请求参数,并将这些参数保存到数据库里。
CGI技术开启了动态Web应用的时代,给了这种技术无限的可能性。
但CGI技术存在很多缺点,其中最大的缺点就是开发动态Web应用难度非常大,而且在性能等各方面也存在限制。
到1997年时,随着Java语言的广泛使用,Servlet技术迅速成为动态Web应用的主要开发技术。
Servlet是JAVA平台下CGI技术的代替品。
在Servlet技术规范下,浏览器向Web服务器内指定的Servlet发送请求,Web服务器根据Servlet生成对客户端的响应。
图:
Servlet的响应流程图
实际上,这是后来所有的动态Web编程技术所使用的模型,这种模型都需要一个动态的程序,或者一个动态页面,当客户端向该动态程序或动态页面发送请求时,Web服务器根据该动态程序来生成对客户端的响应。
Servlet一种在JAVA代码中嵌入HTML的方式,需要在JAVA代码中一行一行的进行HTML代码的生成及输出,在现在的技术条件下,我们简直无法想象当时JAVAWEB开发的复杂度。
到了1998年,微软发布了ASP2.0。
它是WindowsNT4OptionPack的一部分,作为IIS4.0的外接式附件。
它与ASP1.0的主要区别在于它的外部组件是可以初始化的,这样,在ASP程序内部的所有组件都有了独立的内存空间,并可以进行事务处理。
标志着ASP技术开始真正作为动态Web编程技术。
当ASP技术在世界上广泛流行时,人们很快感受到这种简单的技术的魅力:
ASP使用VBScript作为脚本语言,它的语法简单、开发效率非常高。
而且,世界上已经有了非常多的VB程序员,这些VB程序员可以很轻易地过渡成ASP程序员——因此,ASP技术马上成为应用最广泛的动态Web开发技术。
随后,由Sun带领的Java阵营,立即发布了JSP标准,从某种程度上来看,JSP是Java阵营为了对抗ASP推出的一种动态Web编程技术。
ASP和JSP从名称上如此相似,但它们的运行机制存在一些差别,这主要是因为VBScript是一种脚本语言,无需编译,而JSP使用Java作为脚本语句——但Java从来就不是解释型的脚本语言,因此JSP页面并不能立即执行。
因此,JSP必须编译成Servlet,这就是说:
JSP的实质还是Servlet。
不过,书写JSP比书写Servlet简单得多。
作为一个和ASP对抗的技术,简单就是JSP的最大优势。
JSP与SERVLET的最大区别在与Servlet是在JAVA代中嵌入HTML,而JSP是在HTML中嵌入JAVA代码。
在最初的JSP开发模式下,整个Web应用几乎全部由JSP页面组成,JSP页面接收处理客户端请求,对请求处理后直接做出响应。
用少量的JavaBean来处理数据库连接、数据库访问等操作。
这种模式就是人们常说的JSPModel1。
图:
Jspmodel1结构图
Model1模式的实现比较简单,适用于快速开发小规模项目。
但从工程化的角度看,它的局限性非常明显:
JSP页面身兼View和Controller两种角色,将控制逻辑和表现逻辑混杂在一起,从而导致代码的重用性非常低,增加了应用的扩展性和维护的难度。
因此,JAVA技术人员开始引入MVC架构来处理控制逻辑和表现逻辑的分离。
这就是人们所说的JSPModel2。
这种模式下,将Servlet作为前端控制器,负责接收客户端发送的请求,在Servlet中只包含控制逻辑和简单的前端处理;然后,调用后端JavaBean来完成实际的逻辑处理;最后,转发到相应的JSP页面处理显示逻辑。
图:
Jspmodel2结构图
Model2下JSP不再承担控制器的责任,它仅仅是表现层角色,仅仅用于将结果呈现给用户,JSP页面的请求与Servlet(控制器)交互,而Servlet负责与后台的JavaBean通信。
在Model2模式下,模型(Model)由JavaBean充当,视图(View)由JSP页面充当,而控制器(Controller)则由Servlet充当。
由于引入了MVC架构,使Model2具有组件化的特点,更适用于大规模应用的开发。
Model2提供了更好的可扩展性及可维护性,降低系统后期维护的复杂度。
但也增加了前期开发的复杂程度。
原本需要一个简单的JSP页面就能实现的应用,在Model2中被分解成多个协同工作的部分,需花更多时间才能真正掌握其设计和实现过程。
MVC架构的引入为Java的web开发领域带来了全新的变革。
各种webMVC框架的出现使得开发人员从原来的泥潭中爬出,开始专注于其他领域的问题。
在前端,技术员开始寻找jsp的替代方案。
在服务端,技术员把更多的目光转向如何提高系统的可移植性、安全性、可伸缩性、负载平衡和可重用性。
Javaweb开发需要更多的服务端框架来为服务端提供事务、安全、通讯、多线程、内存优化管理等服务,以简化web应用的开发、管理和部署。
或者可以说,MVC框架的出现,将javaweb开发带入了J2ee时代。
(紧跟着微软也发布了ASP.NET技术,提供一种完全不一样的web编程模型,此处不对ASP.net技术进行更多描述。
)
1.2.java开发框架简史
前面说过,MVC架构的引入是javaweb开发领域的里程碑。
它为web应用开发划分了清晰的体系结构。
但是MVC架构的实现方式并不统一,这就是为什么出现那么多的WEBMVC框架的原因。
不管是什么样的webMVC框架,都必然将系统划分成View-Controller-Model三部分,分别对应多层体系的表现层、控制层与业务逻辑层。
其中表现层负责HTML页面的生成;控制层负责响应客户请求,控制页面导航;业务层则进行应用逻辑处理。
良好的分层结构,使java技术员得以专注于特定领域的技术发展,不同层面的技术结构都得以进行各种不同的技术变革。
在表现层,jsp是最初唯一的选择。
但java技术员从来都不会满足这种唯一选择的技术路线,他们不断提出各种替代jsp的方案,为表现层如何解析java数据模型进行页面显示寻求更为简单有效的规约。
于是Velocity、Webmacro、FreeMarker等模板语言开始进入前端开发人员的视线。
而在服务端,技术员开始将数据的读取与存储功能从业务层剥离,使业务层划分成应用层和持久层。
应用层负责事务管理与逻辑处理,持久层则负责与关系数据库、文件等的数据读取与存储操作(或者大家更习惯把持久层叫做数据访问层)。
EJB也是当时服务端唯一的技术选择。
EJB是一种Server方的组件结构,它可以非常简单的开发基于java的企业级的分布式对象应用(类似于DCOM?
)。
EJB的事务导向特性,为服务端提供了良好的事务支持,SessionBean在应用层处理业务逻辑,进行事务控制,EntityBean则在持久层负责数据的读取于存储。
尽管EJB是一个非常强大的服务端框架。
但是同时EJB也是一个比较复杂而且高度依赖j2ee容器的框架。
前面也说过,java技术员从来不会满足于这种唯一的选择,特别是在有些人认为EJB存在着这样那样的毛病的情况下。
所以必然会有人去探索EJB之外的服务端框架解决方案(java领域的特性,有利有弊吧)。
于是,有个牛人写了本《ExpertOneononeJ2EEDevelopmentWithoutEJB》的书,阐述了在不用EJB的情况下进行J2ee开发的理念。
并向大家推荐了一个有更多的牛人按照这个理念而开发的一个叫Spring的开发框架-—这个就是我们要使用的整套框架的核心。
2.搭建我们的javaweb开发框架-Springline
2.1.框架的基本要求
从前面的描述,我们似乎可以做出这样的结论:
一个完整的良好的javaweb开发框架会将系统的体系结构至少划分成四个层次:
表现层、控制层、应用层和持久层。
她必然使用MVC架构处理表示层和应用层的分离;必然包含一个持久层框架进行持久化处理;必须提供良好的事务支持。
这是我们对一个javaweb开发框架的基本要求,当然我们可以要求得更多一些:
如更好的服务端特性支持,为每个层次建立系列的类层次体系,为各层代码的编写封装一些共性的功能;提供代码生成工具减少代码的编写量等等。
2.2.框架的组成
尽管EJB与Spring的争论依然存在,我们仍然选择Spring作为我们的核心框架,原因可以很简单,因为它好用。
Spring是一个轻型容器(light-weightcontainer),其核心是Bean工厂(BeanFactory),用以构造我们所需要的各种对象。
在此基础之上,Spring提供了AOP(Aspect-OrientedProgramming,面向层面的编程)的实现,用它来提供非管理环境下申明方式的事务、安全等服务;对Bean工厂的扩展ApplicationContext更加方便我们实现J2EE的应用;DAO/ORM的实现方便我们进行数据库的开发;WebMVC和SpringWeb提供了JavaWeb应用的框架或与其他流行的Web框架进行集成。
我们将建立一个以Spring为核心、依赖Spring的IOC容器(也就是Spring的Bean工厂)管理所有JAVA对象的生命周期及对象间的依赖关系;集成Hibernate实现持久层管理;为业务层提供声明式事务管理;利用SpringMVC框架实现页面导航控制及响应控制;集成Velocity模板语言实现页面展现的一套整合开发框架。
框架的体系结构图如下图所示:
因为框架以Spring为核心,所以我给它起了个名字,叫Springline。
持久层
框架利用Spring的ORM框架与Hibernate的集成实现系统的持久层。
Hibernate是一个开源的持久化框架,它管理Java类与数据库表的映射,并提供种通过操作对象模型来实现数据库数据读取和存储的编程模型。
提供对象模型数据查询和操作的方法,大幅度减少了开发时人工使用SQL和JDBC处理数据的代码量。
Spring的ORM框架使用IOC的便捷特性为各种持久化框架的集成提供了很好的支持。
通过封装数据访问异常、提供通用的资源管理等手段为程序员提供更为简单有效的编程模型,进一步降低持久层的代码量。
最主要的是,Spring建立了一套DataAcessObject类体系,使程序员可以以一种一致的编程模型使用JDBC、JDO、Hibernate、iBatis等各种数据访问技术,并可以自行扩展Spring的DAO体系以增加对其他数据访问技术的支持。
统一的编程模型可以在很大程度上降低转换持久化框架的代价。
(目前Spring的DAOSupport体系只能提供一种一致的编程模型,还不能提供一致的编程接口,如果Spring能够封装统一的编程接口,那么甚至可以不需要改变持久层的代码就可以实现持久层框架的转换,当然,这只是个人的想法,估计是无法实现,否则Spring早就搞定了)。
应用层
Spring的ORM框架利用Spring的AOP框架封装持久化框架的事务管理体系,为持久层提供透明的事务支持,使持久层代码无需考虑事务的控制。
同时为应用层提供提供声明式的事务管理,使业务层的代码也不会受事务模型的的变化所影响。
(参考Spring文档12.1节,中间层数据访问-使用ORM工具进行数据访问)
控制层
Spring的MVC框架将Spring将对象细分成很多不同的角色:
如控制器(Controller)、可选的命令对象(Command)、视图解析器(ViewResolver)以及传递到视图的模型(Model)等。
其中控制器的主要主要职责就是响应客户端的请求,根据需要将请求封装成Command对象,交由业务层进行业务逻辑处理。
然后指定下一步要呈现的视图名称,组织视图所需的数据模型。
Spring的MVC框架定义了Controller接口的返回值类型为ModelAndView,view为视图的名称,model就是包含所需数据模型的Map对象。
通过这样的封装规范控制层与表现层的数据传递。
控制层对象都必须实现Controller接口。
Spring的MVC框架为处理各种不同的需求建立一套Controller类层次体系,对各种行为进行了封装。
其中最常用的就是SimpleFormController和MultiActionController,Springline框架也在这两个控制器的基础上进行了进一步的封装。
编写控制层代码的时候,可直接从Springline封装的控制器基类继承即可。
(更多详细说明,请参考Spring文档的TheWEB章节)
表示层
Spring的ViewResolver和View是Spring的视图处理方式中特别重要的两个接口。
ViewResolver提供了从视图名称到实际视图的映射。
View处理请求的准备工作,并将该请求提交给某种具体的视图技术。
ViewResolver和View类层次体系把View层技术与MVC框架的其他部分分离开来,使得Spring可以很便捷的实现与多种视图技术的集成。
在这里我们使用Velocity模板语言来实现我们的表示层。
Spring与Velocity的集成请参考Spring文档的Theweb-集成视图技术章节
Velocity模板的编写请参考velocity中文手册.doc
2.3.让Springline开始工作
描述如何配置才能让框架整合运行。
也可参考spring-mvc-step-by-step的说明。
Servlet规范中的javaweb应用目录结构规范
在JavaWeb应用中可以包含HTML文档、Servlet、JSP和相关Java类等。
为了让Servlet容器能顺利地找到JavaWeb应用中的各个组件,Servlet规范规定,JavaWeb应用必须采用固定的目录结构,即每种类型的组件在Web应用中都有固定的存放目录。
Servlet规范还规定,JavaWeb应用的配置信息存放在WEB-INF/web.xml文件中,Servlet容器从该文件中读取配置信息。
在发布某些Web组件(如Servlet)时,需要在web.xml文件中添加相应的关于这些Web组件的配置信息。
JavaWeb应用具有固定的目录结构。
假定开发一个名为helloapp的JavaWeb应用,其最基本的目录结构应如下所示:
在WEB-INF目录的classes及lib子目录下,都可以存放Java类文件。
在运行时,Servlet容器的类加载器先加载classes目录下的类,再加载lib目录下的JAR文件(Java类库的打包文件)中的类。
因此,如果两个目录下存在同名的类,classes目录下的类具有优先权。
Web.xml:
javaweb应用的起点
Servlet规范中定义了部署描述文件web.xml,这个xml文件用于控制Web应用程序的许多方面。
包括为servlet分配自定义的统一资源定位符(URL),规定整个应用程序和特定servlet的初始化参数,控制session会话的失效时间,声明过滤器,声明安全角色,通过声明安全角色来限制Web资源的访问权限等。
更多具体内容参考《web.xml详解.doc》
DispatcherServlet:
前端控制器
Web框架一般是通过一个Servlet提供统一的请求入口,将指定的资源映射到这个servlet,在这个servlet中进行框架的初始化配置,访问Web页面中的数据,进行逻辑处理后,将结果数据与的表现层相融合并展现给用户。
Spring的dispatcherServlet就是这样的一个东西。
我们需要在我们的web.xml中进行如上图所示的定义,才能使用spring为我们提供的web框架来响应客户端的*.do和*.action请求。
想了解更多,还是得看Spring的文档相关章节
ContextLoaderListener:
bean工厂从这里启动
Spring的IOC容器可以使用ContextLoader以声明的方式创建(当然你也可以自己以编程的方式来控制)。
ContextLoader机制有两种方式,ContextLoaderListener和ContextLoaderServlet,他们功能相同但是listener不能在Servlet2.3容器下使用。
servletcontextlistener是初始化SpringApplicationContext理想的方式。
你可能愿意选择ContextLoaderServlet,虽然是一样的,但决定权在于你。
在web.xml中进行如下定义即可注册一个Spring的IOC容器:
监听器首先检查contextConfigLocation参数,如果它不存在,它将使用/WEB-INF/applicationContext.xml作为默认值。
如果已存在,它将使用分隔符(逗号、冒号或空格)将字符串分解成应用上下文件位置路径。
可以支持ant-风格的路径模式,如/WEB-INF/*Context.xml(WEB-INF文件夹下所有以"Context.xml"结尾的文件)。
或者/WEB-INF/**/*Context.xml(WEB-INF文件夹及子文件夹下的以"Context.xml"结尾的文件)。
ContextLoaderServlet同ContextLoaderListener一样使用'contextConfigLocation'参数。
ViewResole:
集成表现层引擎Velocity
如何通过viewResole的配置,集成Velocity模板
管理Hibernate
如何配置Hibernate,数据源、sessionFactory
所谓的声明式事务
说明spring如何提供声明式事务,事务的策略有哪些,我们的框架做了哪些默认设置。
2.4.一个简单的例子
系统角色管理:
实现角色的新增、修改、删除及查询功能,要求新增、修改时同时进行授权操作,删除时需判断角色是否被使用,被使用的角色不许删除。
数据模型如下图:
开发前的准备工作
1、搭建开发环境,参考《搭建JAVA开发环境.doc》。
2、使用eclipse新建javaproject,右键点击项目名称,在弹出菜单中选择Team->ShareProject从SVN服务器下载框架代码到Project中。
3、下载完框架代码后,将得到如下图所示的项目结构:
其中src为源代码路径,放置java的源代码。
dist目录为输出路径,以符合javaweb应用程序规范(参考2.3)的目录存放部署web应用所需的各种文件。
4、再次右键点击项目名称,在弹出菜单中选择Properties,进入如下图所示的项目属性设置界面:
在Source页,设置src为源代码路径,设置输出路径为dist/WEB-INF/classes;在libraries页,使用AddJars导入dist/WEB-INF/lib目录下所有的第三方jar包。
设置完毕,点击OK回到项目视图。
5、再次右键点击项目名称,在弹出菜单中选择MyEclipse->AddWEBProjectCapabilitites(注:
如果已经是web项目了,则看不到该菜单。
),将弹出如下的web能力设置界面:
选择dist目录作为webrootDirectory,并将webcontextRoot修改为发布包部署时的名称(一般采用项目名称)。
6、点集快捷按钮中的发布按钮发布应用程序:
将进入如下图所示的web应用发布界面:
点击Add按钮,发布nnjw项目:
设置Server为我们调试用的Tomat6.x服务器,选择explodedArchvice部署方式(展开方式,方便调试),点击Finish即可完成应用的部署。
完成这些部署之后,就可以开始模块代码的编写。
但是我们还需要了解框架的目录管理约定:
目录名称
说明
src/
org.springline
框架封装
com.console
总控源码根目录,包含组织结构管理、用户管理、角色、菜单、授权等
com.plugins
一些公共功能的根目录:
如代办事宜、序号生成器、简单字典管理器等
com.systemic
应用模块根路径,在其下面按模块划分子目录
dist/
WEB-INF/
view/console
总控所需页面的根目录
view/plugins
插件所需页面的根目录
view/systemic
应用模块页面的根目录,在其下面按模块划分子目录
dist
images
公共图片目录,不受样式变更影响的图片
template(N)
存放不同样式所需图片的目录
script
Javascript文件目录,公共部分和模块应用所需部分该如何区分?
目前没有想到什么好办法
这也就是说,如果我们的模块名称为$module,那么我们为实现应用该模块而添加的java代码应该放在src/com.systemic.$module目录下,对应的页面文件放在dist/WEB-INF/view/systemic/$module目录下。
下面开始建立实现应用模块所需的代码。
为模块建立这样的目录结构
1、在应用包下面建立模块代码包role作为本模块的根目录,并在根目录下建立模块的spring配置文件role.config.xml。
别忘了同时在Web.Xml的contextConfigLocation中增加相应配置,告诉Spring启动时加载配置文件中的对象:
/WEB-INF/config/hibernate.cfg.xml
classpath:
com/console/role/role.config.xml
2、与前面的体系结构图一致,建立controller子目录存放控制层代码,建立service目录存放应用层代码,在Service目录下建立dao目录存放持久层代码
3、上层对象引用下层对象,下层对象不能引用上层对象,使用接口进行对象关联关系的解耦。
所以在service和dao目录存放的都是接口。
在service下建立spring目录存放service接口的实现类。
在dao下建立hibernate目录存放dao接口的实现。
4、Entity目录存放Hibernate代码生成工具生成所需的javabean及ORM映射文件。
这些文件可通过hibernate的相关工具生成。
同时别忘了,在Hibernate.cfg.xml中增加如下配置,以便hibernate进行该映射的管理:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Springline 开发 框架 手册