项目实践精解基于StrutsSpringHibernate的Java应用开发Word文件下载.docx
- 文档编号:16975742
- 上传时间:2022-11-27
- 格式:DOCX
- 页数:70
- 大小:68.18KB
项目实践精解基于StrutsSpringHibernate的Java应用开发Word文件下载.docx
《项目实践精解基于StrutsSpringHibernate的Java应用开发Word文件下载.docx》由会员分享,可在线阅读,更多相关《项目实践精解基于StrutsSpringHibernate的Java应用开发Word文件下载.docx(70页珍藏版)》请在冰豆网上搜索。
•提供一个流程控制器,委派调用业务逻辑和其他上层处理
•处理异常
•为显示提供一个数据模型
•用户界面的验证
以下内容,不该在Struts表示层的编码中经常出现,它们与表示层无关的。
•与数据库直接通信
•与应用程序相关联的业务逻辑及校验
•事务处理
在表示层引入这些代码,则会带来高耦合和难以维护的后果。
典型的Web应用的后端是持久层。
开发者总是低估构建他们自己的持久层框架的挑战性。
系统内部的持久层不但需要大量调试时间,而且还经常因为缺少功能使之变得难以控制,这是持久层的通病。
幸运的是,有几个对象/关系映射(Object/RelationMapping,ORM)开源框架很好地解决了这类问题,尤其是Hibernate。
Hibernate为Java提供了持久化机制和查询服务,它还给已经熟悉SQL和JDBCAPI的Java开发者创造了一个学习桥梁,使他们学习起来很方便。
Hibernate的持久对象是基于POJO(PlainOldJavaObject)和Java集合(collections)的。
此外,使用Hibernate并不妨碍你正在使用的IDE(IntegratedDevelopmentEnviroment)。
下面是Hibernate所负责的内容。
•如何查询对象的相关信息。
Hibernate是通过一个面向对象的查询语言(HQL)或正则表达的API来完成查询的。
HQL非常类似于SQL,只是把SQL里的table和columns用Object和它的fields代替。
HQL语言容易理解且文档做得很好。
HQL是一种面向对象查询的自然语言,很容易就能学会它。
•如何存储、更新、删除数据库记录。
•Hibernate这类的高级ORM框架支持大部分主流数据库,并且支持父表/子表(Parent/child)关系、事务处理、继承和多态。
一个典型Web应用的中间部分是业务层或服务层。
从编码的视角来看,这层是最容易被忽视的。
我们往往在用户界面层或持久层周围看到这些业务处理的代码,这其实是不正确的。
因为它会造成程序代码的高耦合,这样一来,随着时间推移,这些代码将很难维护。
幸好,针对这一问题有几种框架(Framework)存在,最受欢迎的两个框架是Spring和PicoContainer。
这些也被称为轻量级容器(microcontainer),它们能让你很好地把对象搭配起来。
这两个框架都着手于“依赖注射”(dependencyinjection),还有我们知道的“控制反转”(InversionofControl,IoC)这样的简单概念。
这里,我们将关注于Spring的依赖注射和面向方面编程。
另外,Spring把程序中所涉及到的包含业务逻辑和数据存取对象(DataAccessObject)的Objects——transactionmanagementhandler(事务管理控制)、ObjectFactories(对象工厂)、serviceobjects(服务组件)都通过XML配置联系起来。
后面我们会通过项目和实例来揭示Spring是怎样运用这些概念的。
下面是业务层所负责的。
•处理应用程序的业务逻辑和业务校验
•管理事务
•提供与其他层相互作用的接口
•管理业务层级别的对象的依赖
•在表示层和持久层之间增加了一个灵活的机制,使得他们不直接联系在一起
•通过揭示从表示层到业务层之间的上下文(Context)来得到业务逻辑(businessservices)
•管理程序的执行(从业务层到持久层)
既然我们致力于一个Web的应用,我们就需要一个对象集合,让它在不同层之间移动。
域模块层由实际需求中的业务对象组成,比如订单明细(OrderLineItem)、产品(Product)等。
开发者在这层不用管那些数据传输对象(DataTransferObject),而仅关注域对象(domainobject)即可。
例如,Hibernate允许你将数据库中的信息存入域对象(domainobjects),这样你可以在连接断开的情况下把这些数据显示到用户界面层,而那些对象也可以返回给持久层,从而在数据库里更新。
而且,你不必把对象转化成DTO(这可能导致它在不同层之间的传输过程中丢失)。
这个模型使得Java开发者能很自然运用面向对象编程(Object-OrientedProgramming),而不需要附加的编码。
本书围绕上述架构,通过一个完整的项目onlinebookstore来具体展开Struts-Spring-Hibernate这3部分的讲解。
项目开发并不是一个简单的过程,我们需要遵循一些开发流程。
一个项目的开发会被分成很多步骤来实现,每一个步骤都有自己的起点和终点。
也正如此,使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的“坎”,使其难于达到该步骤开始或是终结的条件,开发过程也就不会一帆风顺。
不同的开发模式其实就是将步骤的起点和终点重新定义,甚至重新组合排列,虽然任何一个开发模式最终目的都是完成软件项目的开发,但期间所经历的过程不一样,过程步骤之间的起点和终点的定义不同,所带来的“坎”也就不一样,项目周期自然各不相同。
因此,根据软件项目的实际情况选择一个适合的开发模式能减少开发周期中“坎”的出现次数与难度,可以很大程度地缩短开发周期。
我们首先了解一下传统瀑布式开发流程,如图2-1所示。
图2-1
瀑布式(Waterfall)开发流程
瀑布模型是由在1970年首先提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析、设计、实现、测试(确认)、集成和维护坚定而顺畅地进行的。
线性模型太理想化,太单纯,以至很多人认为瀑布模型已不再适合现代的软件开发模式,几乎被业界抛弃。
我们向大家推荐的是统一开发流程RUP(RationalUnifiedProcess),它是目前最流行的一套项目开发流程模式,其基本特征是通过多次迭代完成一个项目的开发,每次迭代都会带来项目整体的递增,如图2-2所示。
从纵向来看,项目的生命周期或工作流包括项目需求分析、系统分析和设计、实现、测试和维护。
从横向来看,项目开发可以分为4个阶段:
起始(Inception)、细化(Elaboration)、建造(Construction)和移交(transition)。
每个阶段都包括一次或者多次的迭代。
在每次迭代中,根据不同的要求或工作流(如需求、分析和设计等)投入不同的工作量。
也就是说,在不同阶段的每次迭代中,生命周期的每个步骤是同步进行的,但权重不同。
这是与传统瀑布式开发流程区别最大的地方。
2.1.1
项目生命周期
1.项目需求分析
需求分析阶段的活动包括定义潜在的角色(角色指使用系统的人,以及与系统相互作用的软、硬件环境)、识别问题域中的对象和关系,以及基于需求规范说明和角色的需要发现用例(use-case)和详细描述用例。
2.系统分析和设计
系统分析阶段是基于问题和用户需求的描述,建立现实世界的计算机实现模型。
系统设计是结合问题域的知识和目标系统的体系结构(求解域),将目标系统分解为子系统,之后基于分析模型添加细节,完成系统设计。
3.实现
实现又称编码或开发阶段,也就是将设计转换为特定的编程语言或硬件,同时保持先进性、灵活性和可扩展性。
在这个阶段,设计阶段的类被转换为使用面向对象编程语言编制(不推荐使用过程语言)的实际代码。
这一任务可能比较困难,也可能比较容易,主要取决于所使用的编程语言本身的能力。
4.测试和维护
测试用于检验系统是否满足用户功能需求,以便增加用户对系统的信心。
系统经过测试后,整个开发流程告一段落,进入运行维护或新的功能扩展时期。
2.1.2
项目开发阶段
1.起始阶段(TheInceptionPhase)
对于新的开发项目来说,起始阶段是很重要的。
在项目继续进行前,我们必须处理重要的业务与需求风险。
对于那些增强现有系统的项目,起始阶段是比较短暂的,但是其目的仍是确定该项目的实施价值及可行性。
起始阶段有4个重要活动。
•制定项目的范围
•计划并准备业务案例
•综合分析,得出备选构架
•准备项目环境
2.细化阶段(TheElaborationPhase)
细化阶段的目标是为系统构架设立基线(baseline),为在构建阶段开展的大量的设计与实施工作打下坚实的基础。
构架是通过考虑最重要的需求与评估风险演进而来的,构架的稳定性是通过一个或多个构架原型(prototype)进行评估的。
3.构建阶段(TheConstructionPhase)
构建阶段的目标是完成系统开发。
构建阶段从某种意义上来看是一个制造过程,其中,重点工作就是管理资源、控制操作,以优化成本、日程和质量。
因此,在此阶段,管理理念应该进行一个转换,从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。
构建阶段的每次迭代都具有3个关键活动。
•管理资源与控制过程
•开发与测试组件
•对迭代进行评估
4.交付阶段(TheTransitionPhase)
交付阶段的焦点就是确保软件对于最终用户是可用的。
交付阶段包括为发布应用而进行的产品测试,在用户反馈的基础上做微小的调整等内容。
在生命周期的这个时刻,用户反馈主要集中在精确调整产品、配置、安装,以及可用性等问题上。
交付阶段的关键活动如下:
•确定最终用户支持资料
•在用户的环境中测试可交付的产品
•基于用户反馈精确调整产品
•向最终用户交付最终产品
最后,作为补充,我们再简单介绍一种新的开发流程:
敏捷开发和极限编程。
2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭的问题,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。
敏捷开发过程的方法很多,主要有SCRUM、Crystal、特征驱动软件开发(FeatureDrivenDevelopment,简称FDD)、自适应软件开发(AdaptiveSoftwareDevelopment,简称ASD),以及最重要的极限编程(eXtremeProgramming,简称XP)。
极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合,使软件能以尽可能快的速度开发出来并向客户提供最高的效益。
XP在很多方面都和传统意义上的软件工程不同,同时,它也和传统得管理和项目计划得方法不同。
这些方法在软件工程和其他管理活动中都有借鉴意义。
XP具有12个过程,只有完全使用12个过程才是真正使用了XP,只是简单使用了其中一个方法并不代表使用了XP。
XP的12个过程如下。
•现场客户(On-siteCustomer)
•计划博弈(PlanningGame)
•系统隐喻(SystemDesign)
•简化设计(SimpleDesign)
•集体拥有代码(CollectiveCodeOwnership)
•结对编程(PairProgramming)
•测试驱动(Test-driver)
•小型发布(SmallRelease)
•重构(Refactoring)
•持续集成(Continousintegration)
•每周40小时工作制(40-hourWeeks)
•代码规范(CodingStandards)
下面是极限编程的有效实践。
完整团队XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。
这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
计划博弈是持续的、循序渐进的。
每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
简单设计团队保持设计恰好和当前的系统功能相匹配。
它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
结对编程所有的产品软件都是由两个程序员并排坐在一起在同一台机器上构建的。
测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。
同样,它更是一种编写文档的行为。
编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。
程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净,具有表达力。
持续集成团队总是使系统完整地被集成。
一个人拆入(Checkin)后,其他所有人负责代码集成。
集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。
没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其他方面的开发。
编码标准系统中所有的代码看起来就好像是由一人单独编写的。
隐喻将整个系统联系在一起的全局视图,它是系统的未来影像,使得所有单独模块的位置和外观变得明显直观。
如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
可持续的速度团队只有持久才有获胜的希望。
他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。
极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。
极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。
UML(UnifiedModelingLanguage)是实现项目开发流程的一个重要工具,它是一套可视化建模语言,由各种图来表达。
图就是用来显示各种模型元素符号的实际图形,这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。
一般来说,一个系统模型拥有多个不同类型的图,一个图是某个特定视图的一部分。
通常,图是被分配给视图来绘制的。
另外,根据图中显示的内容,某些图可以是多个不同视图的组成部分。
图具体分为静态模型和动态模型两大类。
其中,静态模型包括:
•用例图(Use-caseDiagrams)
•类图(ClassDiagrams)
•对象图(ObjectDiagrams)
•组件图(ComponentDiagrams)
•部署图(DeploymentDiagrams)
动态模型包括:
•序列图(SequenceDiagrams)
•协作图(CollaborationDiagrams)
•状态图(StateChartDiagrams)
•行为图(ActivityDiagrams)
2.2.1
用例图
用例图(Use-caseDiagram)显示多个外部参与者,以及他们与系统之间的交互和连接,如图2-3所示。
一个用例是对系统提供的某个功能(该系统的一个特定用法)的描述。
虽然实际的用例通常用普通文本来描述,但是也可以利用一个活动图来描述用例。
用例仅仅描述系统参与者从外部通过对系统的观察而得到的那些功能,并不描述这些功能在系统内部是如何实现的。
也就是说,用例定义系统的功能需求。
图2-3
一个超市系统的用例图
2.2.2
类图
类图(ClassDiagram)用来显示系统中各个类的静态结构,如图2-4所示。
类代表系统内处理的事物。
这些类可以以多种方式相互连接在一起,包括关联(类互相连接)、依赖(一个类依赖/使用另一个类)、特殊化(一个类是另一个类的特化)或者打包(多个类组合为一个单元)。
所有的这些关系连同每个类的内部结构都在类图中显示。
其中,一个类的内部结构是用该类的属性和操作表示的。
因为类图所描述的结构在系统生命周期的任何一处都是有效的,所以通常认为类图是静态的。
图2-4
旅馆系统的类图
我们常常会使用特殊化(Specialize)、一般化(Generalize)、特化(Specialization)和泛化(Generalization)这几个术语来描述两个类之间的关系。
例如,对于一个类A(即父类)派生出另一个类B(即子类)这样一个过程,也常常这样描述:
类A可以特殊化为类B,而类B可以一般化为类A;
或者类A是类B的泛化,而类B是类A的特化。
一个系统一般都有多个类图——并不是所有的类都放在一个类图中——并且一个类可以参与到多个类图中。
2.2.3
对象图
对象图(ObjectDiagram)是类图的一个变体,它使用的符号与类图几乎一样。
对象图和类图之间的区别是:
对象图用于显示类的多个对象实例,而不是实际的类。
所以,对象图就是类图的一个实例,显示系统执行时的一个可能的快照——在某一时间点上系统可能呈现的样子。
虽然对象图使用与类图相同的符号,但是有两处例外:
用带下划线的对象名称来表示对象和显示一个关系中的所有实例,如图2-5所示。
图2-5
显示类的类图和显示类的实例的对象图
虽然对象图没有类图那么重要,但是它们可以用于为一个复杂类图提供示例,以显示实际和关系可能的样子。
另外,对象图也可被作为协作图的一部分,用于显示一群对象之间的动态协作关系。
2.2.4
状态图
一般来说,状态图(StateDiagram)是对类的描述的补充。
它用于显示类的对象可能具备的所有状态,以及那些引起状态改变的事件,如图2-6所示。
对象的一个事件可以是另一个对象向其发送的消息,例如到了某个指定的时刻,或者已经满足了某条件。
状态的变化称之为转换(Transition)。
一个转换也可以有一个与之相连的动作,后者用以指定完成该状态转换应该执行的操作。
在实际建模时,并不需要为所有的类都绘制状态图,仅对那些具有多个明确状态的类,并且类的这些不同状态会影响和改变类的行为才绘制类的状态图。
另外,也可以为系统绘制整体状态图。
图2-6
电梯系统的状态图
2.2.5
序列图
序列图(SequenceDiagram)显示多个对象之间的动态协作,如图2-7所示。
序列图重点是显示对象之间发送的消息的时间顺序。
它也显示对象之间的交互,也就是在系统执行时,某个指定时间点将发生的事情。
序列图由多个用垂直线显示的对象组成,图2-7中时间从上到下推移,并且序列图显示对象之间随着时间的推移而交换的消息或函数。
消息是用带消息箭头的直线表示的,并且它位于垂直对象线之间。
时间说明以及其他注释放到一个脚本中,并将其放置在顺序图的页边空白处。
图2-7
打印服务器的序列图
2.2.6
协作图
协作图(CollaborationDiagram)像顺序图一样显示动态协作。
为了显示一个协作,通常需要在顺序图和协作图之间做选择。
除了显示消息的交换(称之为交互)以外,协作图也显示对象以及它们之间的关系(上下文)。
通常,选择序列图还是协作图的决定条件是:
如果时间或顺序是需要重点强调的方面,那么选择序列图;
如果上下文是需要重点强调的方面,那么选择协作图。
序列图和协作图都用于显示对象之间的交互。
协作图可当做一个对象图来绘制,它显示多个对象以及它们之间的关系(利用类/对象图中的符号来绘制),如图2-8所示。
协作图中对象之间绘制的箭头显示对象之间的消息流向。
图2-8中的消息上放置标签,用于显示消息发送的顺序。
协作图也可以显示条件、迭代和返回值等信息。
当开发人员熟悉消息标签语法之后,就可以读懂对象之间的协作,以及跟踪执行流程和消息交换顺序。
协作图也可以包括活动对象,这些活动对象可以与其他活动对象并发地执行。
图2-8
打印服务器的协作图
2.2.7
活动图
活动图(ActivityDiagram)用于显示一系列顺序的活动,如图2-9所示。
尽管活动图也可以用于描述像用例或交互这类的活动流程,但是一般来说,它主要还是用于描述在一个操作内执行的那些活动。
活动图由多个动作状态组成,后者包含将被执行的活动(即一个动作)的规格说明。
当动作完成后,动作状态将会改变,转换为一个新的状态(在状态图内,状态在进行转换之前需要标明显式的事件)。
于是,控制就在这些互相连接的动作状态之间流动。
同时,在活动图中也可以显示决策和条件,以及动作状态的并发执行。
另外,活动图也可以包含那些被发送或接收的消息的规格说明,这些消息是被执行动作的一部分。
图2-9
打印服务器的活动图
2.2.8
组件图
组件图是用代码组件来显示代码物理结构的。
其中,组件可以是源代码组件、二进制组件或一个可执行的组件。
因为一个组件包含它所实现的一个或多个逻辑类的相关信息,于是就创建了一个从逻辑视图到组件视图的映射。
根据组件图中显示的那些组件之间的依赖关系,可以很容易地分析出其中某个组件的变化将会对其他组件产生什么样的影响。
另外,组件也可以用它们输出的任意的接口来表示,并且它们可以被聚集在包内。
一般来说,组件图用于实际的编程工作中,如图2-10所示。
图2-10
显示代码组件之间依赖关系的组件图
2.2.9
部署图
部署图(DeploymentDiagram)用于显示系统中的硬件和软件的物理结构。
这些部署图可以显示实际的计算机和设备(节点),同时还有它们之间的必要连接,也可以显示这些连接的类型,如图2-11所示。
在图中显示的那些节点内,已经分配了可执行的组件和对象,以显示这些软件单元分别在哪个节点上运行。
另外,部署图也可以显示组件之间的依赖关系。
图2-11
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 实践 基于 StrutsSpringHibernate Java 应用 开发
链接地址:https://www.bdocx.com/doc/16975742.html