MVC设计模式与WEB框架技术

MVC设计模式与WEB框架技术

MVC(Model—View—Controller：模型-视图-控制器)设计模式是目前用得比较多的一种设计模式，最早出现在Smalltalk中，后来广泛应用于Java Web应用程序中。它将Web应用分成三层：模型(Model)，视图(View)，控制器(Controller)。

模型是应用程序的主体部分，负责业务逻辑的处理以及业务规则的制定。其本质上封装了包含对数据控制及修改的规则在内的数据和行为，提供了一套查询、改变模型状态的方法。模型位于J2EE架构的业务逻辑层，通常用服务器端JavaBean或EJB实现。

视图是应用程序中负责生成用户界面的部分。视图代表用户交互界面，是应用程序的外在表现。视图一般位于J2EE架构的客户层和Web表示层，通常用JSP／Servelets实现。

控制器是模型和视图的纽带，负责解释用户的输入并将其映射为模型的操作，同时定义应用程序的行为，分派用户的请求并选择恰当的视图用于显示。通过控制器将模型和视图连接起来，可以在模型和视图之间实现松耦散合。控制器位于J2EE架构Web表示层，通常用Servelets实现。

MVC经常作为一种设计模式出现在各种讨论中，但实际上MVC是结构模式而非设计模式。MVC模式与其它设计模式的关系密不可分，把MVC模式视作比设计模式粒度更大、层次更高的架构(模式)较为妥当。MVC体现了“分治"的思想，它将用户界面设计、流程控制和事务逻辑进行了分离，把界面设计同数据操作完全隔离开来，使得整个开发设计清晰，给系统的测试及维护带来了相当多的便利。在J2EE企业应用开发中采用MVC模式，能使软件开发有章可循、结构清晰、缩短开发周期，同时，还能有效的改善软件系统的性能，大大提高软件的可维护行与可扩展性。

在J2EE体系中，应用MVC模式进行W曲应用开发比简单的JSP开发要复杂很多，其学习曲线长难以快速掌握。在开发过程中，开发人员必须以MVC的方式重新思考和设计应用程序，原先只需一个简单的JSP页面就能实现的功能现在要变成多个步骤去设计和实现。因此，从某种意义上来说，开发中引入MVC设计模式会增加额外工作量。

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

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

谈软件架构师如何做好架构设计

1前言

软件架构设计是软件设计的一部分，相当于总体设计，是软件设计过程中一个决定性的环节，架构确定了，软件基本也就定型了。而软件架构师则是软件项目的领军人物，是软件设计过程中最具挑战性的角色，从技术角度来讲，他承担了项目的成败责任。

EEEC给“架构师”的定义为“软件架构师是技术主管”，这就意味着他不仅要有高超的技术才能，还要有很好的领导才能，他的领导能力在团队中和软件质量控制中起着十分重要的作用。作为一个架构师，他要掌握整个软件项目的前景，调节各小组间关系，要让所有的项目组成成员了解大家共同的目的和目标，并发布标准和章程；要能正确理解软件过程，要在宏观上拥有专业知识，应该拥有很好的设计技巧；要是一个很好的沟通员和谈判代表，要能做出正确的决策等，除此，还有许多他要具备的其它素质。

2做好需求调研和分析

为保证软件的可用性，要从需求出发设计架构，即：做软件先做需求，这是软件业内人士的共识，但这项工作做得好的却很少。根据调查，属于需求分析和软件设计错误与缺陷的约占软件错误与缺陷的64%；而属于程序代码错误的仅占36%；而因软件错误积累与放大效应，造成整个软件项目拖延或失败情况的高达20%～60%。这些数据表明，搞好需求调研和分析是软件设计和开发的第一步。架构师必须要在需求调研的初期就介入，以保证需求获取的及时、可靠、准确，并对下步工作起指导作用。进行需求调研，不能就事论事，对用户的需求调研要全面、细致。需求要进行全局性的分析，需要有全局的观点，而不是分散地、根据具体的应用开发而进行的调研，这样才能系统地、本质地、概括地把握软件的功能结构。在调研过程中，自始至终都要有用户方的业务人员参加，尤其是强调高层管理人员的重视和亲自参与，架构师及其相应的工作小组要有足够的沟通和理解能力，要能使业务人员在需求调研阶段起主导作用，架构师仅起协助和引导作用，并提供需求调研的科学方法和过程。2.1熟悉建设单位，定义职能域

在需求调研阶段，架构师首先要全面了解用户中所有人员的需求，首先要了解建设单位的组织机构、业务关系，并根据建设单位中的一些主要业务活动领域，研究定义职能域，这是第一重要任务。职能域是用户功能规划的抽象，应符合建设单位内部各种业务的逻辑关系，而不是现行机构部门的翻版，一经识别，就要保持相对稳定。研制职能域模型时，需要特别注意，要自顶向下规划，并把握好设计职能域的数目；注意用户需求的主次关系，按照重要性、优先级进行权衡取舍。

2.2详细调研各项业务过程及其功能分解

每个职能域都包括一定数目的业务过程，业务过程可以继续分解为业务活动（对应于未来的软件功能），每个功能再分解为更低层的功能，逐级向下分解，直到产生最基本的、不可再分的最小功能单元。

职能域和业务过程都要独立于当前的组织机构，因为组织机构可能变化，部门的分工也会变化，但整个单位的基本职能和业务相对稳定。职能域或业务过程可能横跨两个或多个业务部门。业务过程的确定可以对照组织机构中各部门负责人的职责来考虑，这样，也可能获得未来软件的操作权限、数据权限的分配和功能模块的划分，这些业务过程是一个单位运作的基本工作，不受报告层次和具体负责人变动的影响。

调研前，架构师要对调研的内容事先准备，针对不同管理层的用户询问不同的问题，列出问题清单，将操作层、管理层、决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。调研时，要收集用户工作中涉及的所有内容，如各种单据、报表、处理规则，再将其串成流程图，以流程图为主线，同时把握以下方面：

（1）该流程中是否存在不必要的环节；

（2）流程是否可以简化，是否可以省略一些环节；

（3）流程中的每个处理环节是否起到了增值提效的作用；

（4）哪些流程可以并行处理。

2.3在调研具体业务时工作小组要把握的重点

（1）平均频度

业务发生的频繁程度称为频度，这个数字可以是一个平均值或统计值。频度越高，数据量越大，对响应时间、易操作性等要求就越高。在数据存储时，对大频度的业务或单据要进行充分的考虑。

（2）高峰期的频度

必须保证软件在高峰期的响应时间，对软件进行测试时，要模拟高峰期的业务频度。（3）单据要求

单据上的内容也就是单据的属性，它是进行数据结构设计的最基本依据。数据的精度是定义数据库中字段长度的依据；计算生成方法是设计算法的依据；取值范围与计算生成方法是数据完整性检测的依据。

（4）利于减轻工作量

减轻人员的工作量是采用新软件的一个目的，花费时间最多、处理方法最复杂的地方往往是软件最关键的地方，也是用户将来验收时最关心的地方。实际上有很多报表由于工作量相当大，用户没有足够的人力与时间来进行处理，这时他便想到了计算机。

（5）单据报表流程

要了解单据或报表的来源、单据联数、每联用途、送交单位、送交时间，对来源与去向的追踪可以调查出各个业务、各个单据、各个报表及各个部门之间的联系。

（6）特殊情况的处理与纠错

对于特殊情况的处理，体现了软件灵活性，但这其中也隐含着安全危机。用户领域中有很多“合理但不合法，不合理也不合法”的特殊情况，它们出现的机会比较少，在调研时要将这些易遗漏的问题挖掘出来，这些特殊情况有时是软件必须要处理的。

当用户在某个作业环节出现失误时，手工软件有的采用正规的手续进行纠错，有的则相当随便，这些情况出现的概率也很小，在调研时，可采用穷举的方法，假定在每一个环节都出现失误，逐个环节询问用户的处理方法，防止遗漏。这些细节如果不调研清楚，往往会对软件产生深远的影响。

（7）考虑长远

将来用户需求的变化是很正常的现象，如果仅仅着眼于现在，而不对将来有所考虑，软件的寿命便不会长久，要将以后可能的变化考虑在内。需求获取后，务必要将调研的成果编制为文档，可视化需求调研，提供不同的图给不同层次的用户进行确认。对高层领导，可提供总体职能域图或业务流程图，对业务管理人员可提供业务流程图或业务活动图，甚至可以画出用户界面的草图。

3需求分析与设计

架构师所带领的团队做出的关于软件体系结构的决策，将直接影响软件开发的难度和软

件维护的难易度，最终决定软件开发的成败。

作为一个架构师，在进行架构设计时，必须具备以下基本能力：

（1）他要把整个团队组织在架构周围，并积极地投入到计划活动上，要把架构转化完成任务的先后顺序，这样才能及时地确定在什么位置用什么技术。

（2）架构师要在技术上做宏观决策，不必关心细节化的事情，由于技术的变化过于频繁，架构师要时与这些变化同步；架构师必须至少能对各种技术有一个整体上的了解，能够熟知每种技术特点及优缺点，只有这样，架构设计师才能在特定的应用场景下，正确地选择各种技术来设计软件架构。

（3）架构师要能预测最小化项目中可能出现的风险，因为这直接影响到软件架构的稳定性。

（4）架构师要能与开发人员保持良好的沟通，确保软件设计的实现。

兰亭序

永和九年，岁在癸丑，暮春之初，会于会稽山阴之兰亭，修禊事也。群贤毕至，少长咸集。此地有崇山峻岭，茂林修竹；又有清流激湍，映带左右，引以为流觞曲水，列坐其次。虽无丝竹管弦之盛，一觞一咏，亦足以畅叙幽情。是日也，天朗气清，惠风和畅，仰观宇宙之大，俯察品类之盛，所以游目骋怀，足以极视听之娱，信可乐也。

夫人之相与，俯仰一世，或取诸怀抱，晤言一室之内；或因寄所托，放浪形骸之外。虽取舍万殊，静躁不同，当其欣于所遇，暂得于己，快然自足，不知老之将至。及其所之既倦，情随事迁，感慨系之矣。向之所欣，俯仰之间，已为陈迹，犹不能不以之兴怀。况修短随化，终期于尽。古人云：“死生亦大矣。”岂不痛哉！

每览昔人兴感之由，若合一契，未尝不临文嗟悼，不能喻

之于怀。固知一死生为虚诞，齐彭殇为妄作。后之视今，亦犹今之视昔。悲夫！故列叙时人，录其所述，虽世殊事异，所以兴怀，其致一也。后之览者，亦将有感于斯文。