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）架构师要能与开发人员保持良好的沟通，确保软件设计的实现。