MVC设计模式与WEB框架技术.doc

上传人:s9****2 文档编号:559575902 上传时间:2023-07-23 格式:DOC 页数:4 大小:40.51KB
返回 下载 相关 举报
MVC设计模式与WEB框架技术.doc_第1页
第1页 / 共4页
MVC设计模式与WEB框架技术.doc_第2页
第2页 / 共4页
MVC设计模式与WEB框架技术.doc_第3页
第3页 / 共4页
MVC设计模式与WEB框架技术.doc_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《MVC设计模式与WEB框架技术.doc》由会员分享,可在线阅读,更多相关《MVC设计模式与WEB框架技术.doc(4页珍藏版)》请在金锄头文库上搜索。

1、MVC设计模式与WEB框架技术MVC(ModelViewController:模型-视图-控制器)设计模式是目前用得比较多的一种设计模式,最早出现在Smalltalk中,后来广泛应用于Java Web应用程序中。它将Web应用分成三层:模型(Model),视图(View),控制器(Controller)。 模型是应用程序的主体部分,负责业务逻辑的处理以及业务规则的制定。其本质上封装了包含对数据控制及修改的规则在内的数据和行为,提供了一套查询、改变模型状态的方法。模型位于J2EE架构的业务逻辑层,通常用服务器端JavaBean或EJB实现。 视图是应用程序中负责生成用户界面的部分。视图代表用户交

2、互界面,是应用程序的外在表现。视图一般位于J2EE架构的客户层和Web表示层,通常用JSPServelets实现。 控制器是模型和视图的纽带,负责解释用户的输入并将其映射为模型的操作,同时定义应用程序的行为,分派用户的请求并选择恰当的视图用于显示。通过控制器将模型和视图连接起来,可以在模型和视图之间实现松耦散合。控制器位于J2EE架构Web表示层,通常用Servelets实现。 MVC经常作为一种设计模式出现在各种讨论中,但实际上MVC是结构模式而非设计模式。MVC模式与其它设计模式的关系密不可分,把MVC模式视作比设计模式粒度更大、层次更高的架构(模式)较为妥当。MVC体现了“分治的思想,它

3、将用户界面设计、流程控制和事务逻辑进行了分离,把界面设计同数据操作完全隔离开来,使得整个开发设计清晰,给系统的测试及维护带来了相当多的便利。在J2EE企业应用开发中采用MVC模式,能使软件开发有章可循、结构清晰、缩短开发周期,同时,还能有效的改善软件系统的性能,大大提高软件的可维护行与可扩展性。 在J2EE体系中,应用MVC模式进行W曲应用开发比简单的JSP开发要复杂很多,其学习曲线长难以快速掌握。在开发过程中,开发人员必须以MVC的方式重新思考和设计应用程序,原先只需一个简单的JSP页面就能实现的功能现在要变成多个步骤去设计和实现。因此,从某种意义上来说,开发中引入MVC设计模式会增加额外工

4、作量。 框架技术作为一种重要的软件重用技术,是应用软件部分或整体的可重用设计。它规定了应用的体结构,阐明了整个设计、协作构建之间的依赖关系,责任分配和控制流程,表现为一组抽象类以及它们的实例之间的协作方法。采用框架技术有利于整个系统结构的改善和流程的固定化,有利于提高系统的可重用性和易维护性。对于大型、复杂的应用来说,采用己经开发和测试好的框架进行二次开发,可以提高软件的生产效率、保证软件质量、能够比从头开发取得更为显著的投资回。因此,为了降低上述MVC模式实现的复杂度,可以在应用开发中采用基于MVC模式的Web框架技术。目前,在开源的Java领域,比较流行的Web框架有Struts、Spri

5、ng MVC、WebWork、Tapestry、JSF等。 采用面向组件的开发模式进行Web应用开发,我们的思维是块状的、是面向对象的思维方式261。我们不再关注Servlet底层实现,也不再过问URL的结构;我们通过创建页面来构成应用程序,通过在页面中调用组件来实现页面功能。我们不必关心页面如何通过URL跳转到另外一个页面,也不关心form表单如何通过URL将数据包装在请求中提交到服务器端。面向组件的开发模式有利于我们将注意力集中在页面逻辑实现上,有利于提高工作效率。因此,可以认为面向组件的开发模式比面向元素的开发方式更加先进。谈软件架构师如何做好架构设计1前言 软件架构设计是软件设计的一部

6、分,相当于总体设计,是软件设计过程中一个决定性的环节,架构确定了,软件基本也就定型了。而软件架构师则是软件项目的领军人物,是软件设计过程中最具挑战性的角色,从技术角度来讲,他承担了项目的成败责任。 EEEC给“架构师”的定义为“软件架构师是技术主管”,这就意味着他不仅要有高超的技术才能,还要有很好的领导才能,他的领导能力在团队中和软件质量控制中起着十分重要的作用。作为一个架构师,他要掌握整个软件项目的前景,调节各小组间关系,要让所有的项目组成成员了解大家共同的目的和目标,并发布标准和章程;要能正确理解软件过程,要在宏观上拥有专业知识,应该拥有很好的设计技巧;要是一个很好的沟通员和谈判代表,要能

7、做出正确的决策等,除此,还有许多他要具备的其它素质。 2做好需求调研和分析 为保证软件的可用性,要从需求出发设计架构,即:做软件先做需求,这是软件业内人士的共识,但这项工作做得好的却很少。根据调查,属于需求分析和软件设计错误与缺陷的约占软件错误与缺陷的64%;而属于程序代码错误的仅占36%;而因软件错误积累与放大效应,造成整个软件项目拖延或失败情况的高达20%60%。这些数据表明,搞好需求调研和分析是软件设计和开发的第一步。架构师必须要在需求调研的初期就介入,以保证需求获取的及时、可靠、准确,并对下步工作起指导作用。进行需求调研,不能就事论事,对用户的需求调研要全面、细致。需求要进行全局性的分

8、析,需要有全局的观点,而不是分散地、根据具体的应用开发而进行的调研,这样才能系统地、本质地、概括地把握软件的功能结构。在调研过程中,自始至终都要有用户方的业务人员参加,尤其是强调高层管理人员的重视和亲自参与,架构师及其相应的工作小组要有足够的沟通和理解能力,要能使业务人员在需求调研阶段起主导作用,架构师仅起协助和引导作用,并提供需求调研的科学方法和过程。2.1熟悉建设单位,定义职能域 在需求调研阶段,架构师首先要全面了解用户中所有人员的需求,首先要了解建设单位的组织机构、业务关系,并根据建设单位中的一些主要业务活动领域,研究定义职能域,这是第一重要任务。职能域是用户功能规划的抽象,应符合建设单

9、位内部各种业务的逻辑关系,而不是现行机构部门的翻版,一经识别,就要保持相对稳定。研制职能域模型时,需要特别注意,要自顶向下规划,并把握好设计职能域的数目;注意用户需求的主次关系,按照重要性、优先级进行权衡取舍。 2.2详细调研各项业务过程及其功能分解 每个职能域都包括一定数目的业务过程,业务过程可以继续分解为业务活动(对应于未来的软件功能),每个功能再分解为更低层的功能,逐级向下分解,直到产生最基本的、不可再分的最小功能单元。 职能域和业务过程都要独立于当前的组织机构,因为组织机构可能变化,部门的分工也会变化,但整个单位的基本职能和业务相对稳定。职能域或业务过程可能横跨两个或多个业务部门。业务

10、过程的确定可以对照组织机构中各部门负责人的职责来考虑,这样,也可能获得未来软件的操作权限、数据权限的分配和功能模块的划分,这些业务过程是一个单位运作的基本工作,不受报告层次和具体负责人变动的影响。 调研前,架构师要对调研的内容事先准备,针对不同管理层的用户询问不同的问题,列出问题清单,将操作层、管理层、决策层的需求既联系又区分开来,形成一个金字塔,使下层满足上层的需求。调研时,要收集用户工作中涉及的所有内容,如各种单据、报表、处理规则,再将其串成流程图,以流程图为主线,同时把握以下方面: (1)该流程中是否存在不必要的环节; (2)流程是否可以简化,是否可以省略一些环节; (3)流程中的每个处

11、理环节是否起到了增值提效的作用; (4)哪些流程可以并行处理。2.3在调研具体业务时工作小组要把握的重点 (1)平均频度 业务发生的频繁程度称为频度,这个数字可以是一个平均值或统计值。频度越高,数据量越大,对响应时间、易操作性等要求就越高。在数据存储时,对大频度的业务或单据要进行充分的考虑。 (2)高峰期的频度 必须保证软件在高峰期的响应时间,对软件进行测试时,要模拟高峰期的业务频度。 (3)单据要求 单据上的内容也就是单据的属性,它是进行数据结构设计的最基本依据。数据的精度是定义数据库中字段长度的依据;计算生成方法是设计算法的依据;取值范围与计算生成方法是数据完整性检测的依据。 (4)利于减

12、轻工作量 减轻人员的工作量是采用新软件的一个目的,花费时间最多、处理方法最复杂的地方往往是软件最关键的地方,也是用户将来验收时最关心的地方。实际上有很多报表由于工作量相当大,用户没有足够的人力与时间来进行处理,这时他便想到了计算机。 (5)单据报表流程 要了解单据或报表的来源、单据联数、每联用途、送交单位、送交时间,对来源与去向的追踪可以调查出各个业务、各个单据、各个报表及各个部门之间的联系。 (6)特殊情况的处理与纠错对于特殊情况的处理,体现了软件灵活性,但这其中也隐含着安全危机。用户领域中有很多“合理但不合法,不合理也不合法”的特殊情况,它们出现的机会比较少,在调研时要将这些易遗漏的问题挖

13、掘出来,这些特殊情况有时是软件必须要处理的。 当用户在某个作业环节出现失误时,手工软件有的采用正规的手续进行纠错,有的则相当随便,这些情况出现的概率也很小,在调研时,可采用穷举的方法,假定在每一个环节都出现失误,逐个环节询问用户的处理方法,防止遗漏。这些细节如果不调研清楚,往往会对软件产生深远的影响。 (7)考虑长远 将来用户需求的变化是很正常的现象,如果仅仅着眼于现在,而不对将来有所考虑,软件的寿命便不会长久,要将以后可能的变化考虑在内。需求获取后,务必要将调研的成果编制为文档,可视化需求调研,提供不同的图给不同层次的用户进行确认。对高层领导,可提供总体职能域图或业务流程图,对业务管理人员可

14、提供业务流程图或业务活动图,甚至可以画出用户界面的草图。 3需求分析与设计 架构师所带领的团队做出的关于软件体系结构的决策,将直接影响软件开发的难度和软件维护的难易度,最终决定软件开发的成败。 作为一个架构师,在进行架构设计时,必须具备以下基本能力: (1)他要把整个团队组织在架构周围,并积极地投入到计划活动上,要把架构转化完成任务的先后顺序,这样才能及时地确定在什么位置用什么技术。 (2)架构师要在技术上做宏观决策,不必关心细节化的事情,由于技术的变化过于频繁,架构师要时与这些变化同步;架构师必须至少能对各种技术有一个整体上的了解,能够熟知每种技术特点及优缺点,只有这样,架构设计师才能在特定的应用场景下,正确地选择各种技术来设计软件架构。 (3)架构师要能预测最小化项目中可能出现的风险,因为这直接影响到软件架构的稳定性。 (4)架构师要能与开发人员保持良好的沟通,确保软件设计的实现。

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 生活休闲 > 社会民生

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号