应用框架开发入门

  ===============================================

        为以前公司准备的框架开发讲座的文档，现在放出来，希望对大家有所帮助吧！专门讲框架开发的资料也只有【应用框架的设计与实现】和【Framework的设计与应用】，东摘抄西摘抄就有了如下的文章，关于框架开发的技术这里只列出了大纲，感兴趣的可以去看看【应用框架的设计与实现】，对书的作者除了佩服还是佩服啊！

参考或抄袭资料^-^：

书名	作者	译者
应用框架的设计与实现	Xin Chen	温昱 靳向阳
Framework的设计与应用	黄忠成
企业应用架构模式	Martin Flower	王怀民 周斌
. NET企业服务框架	Christian Nagel	夏桅 金雪根

 ===============================================

应用框架开发入门

框架概述：

一：什么是应用框架：

 首先我们需要定义应用框架是什么。
        术语“框架”对不同的人，含义不同，政治家用这个词描述某些政策和解决问题的某些措施；建筑师用这个词描述建筑物的骨架或结构；软件架构师用这个词描述有助于软件应用开发的一组可重用的设计和代码。
        “结构”一词反映了任何框架的本质。结构无处不在。当开始建筑一座新的建筑物时，你会观察到，它的结构先被搭建。当你写文章或者书籍的时候，你也首先要为你所讨论的内容拟订一个结构，或者称为提纲。通过搭建一个“结构”，可以迫使你着眼全局。对建筑来说，着眼全局将迫使建筑师深入考虑：建筑物的每一部分会如何影响其他每一部分。对写文章来说，着眼全局会迫使你去考虑如何组织每一个主题和文字，才能使读者理解。
       结构在应用开发中扮演了重要角色，一个相当复杂的应用包含了如此之多不断变化的细节部分，以至人们无法把握它们的复杂关系，而结构帮助我们将这些不断变化的细节部分，组织成易于理解的少数几个主要部分。在开发应用时，结构能为我们提供进一步的上下文。应用框架为开发者提供了结构和模板，开发者以此为基线来构建他们的应用系统。这样一个框架通常会包含抽象类，具体类和类之间的预定义交互。开发者在框架之上构建应用，通过重用框架提供的代码和设计，减小了开发工作量，下图概括了应用框架和应用的关系。

应用和应用框架的概括

      当然，许多应用系统的开发没有使用框架，所以，你也许做着开发工作却甚至并不知道框架的概念。在应用开发领域，无论有没有框架，所有事物照样能做。然而，框架能为应用提供很多好处，采用应用框架方法对应用开发大有裨益，而推广应用框架的主旨，就是为了获得这些好处。

      

 

二：应用框架的历史：

       应用框架并不是新概念，各种类型的框架已经被使用大约二十年了，第一个被广泛使用的框架是模型-视图-控制器，俗称为MVC(Model-View Controller)，它是一个Smalltalk用户界面框架。这种使用观察者模式(Observer)的MVC方法已经被很多用户界面系统采用，现在JAVA平台上非常流行的Structs框架就是基于MVC开发的。除了Smalltalk MVC以外，还涌现出了其他一些用户界面框架，它们对开发运行于不同操作系统之上的应用都起到了辅助作用。Windows平台上著名的用户框架有最早的Borland公司的OWL框架,到随后Microsoft的MFC,以及Borland由OWL发展来的VCL，就是其中的佼佼者（说点提外话，很多业内的牛人都认为VCL框架比MFC要先进的多，我是从使用VCL架构过来的，对这个深有体会，甚至现在的.NET框架都更多的是从VCL汲取精华，而不是从MFC）。
       虽然框架概念在用户界面开发中被广泛采用，但是它并不局限于用户界面框架，框架概念也用于通用应用开发。最早的非用户界面框架是Taligent公司开发的CommonPoint，它旨在减少应用开发的工作量，其方法是为开发者提供一个综合编程环境，类似于现在包括Java语言和运行时虚拟机的Java环境。
Sun公司的Java环境和Microsoft公司的.NET环境，不仅提供了新型的语言和虚拟机，还提供了它们自己的框架。在过去几年中，使用Java或者.NET的开发者能够充分感觉到这两种框架为应用开发所带来的好处。Java和.NET都是旨在支持所有业务类型的应用系统的通用框架。因此，它们不能包含任何业务领域相关的类和设计。然而，基于这些通用框架之上的业务框架，可以为很多特定业务领域提供相关服务和专门支持。
       IBM也开发了自己的面向业务领域的框架，被称为San Francisco项目，它是用Java开发的，由针对不同业务领域的应用框架组成，例如，定单管理，仓库管理，财务管理等。与Java和.NET这些通用框架不同, San Francisco 框架是专门为特定业务领域设计的.

三:为何使用应用框架：

 

使用应用框架有五大优点：模块化，可重用性，可扩展性，简单性，可维护性。

A：模块化

模块化就是把应用分割成多个组件或模块。这样，开发者就可以采用各个模块互不影响的方式使用应用框架----希望使用应用框架某个组件的开发者，不会受到框架其他组件潜在变化的影响。当开发者基于框架之上构建应用时，他们的开发活动会更好的隔离开，而不受应用框架其他部分变化的影响；从而，开发效率显著提高了，把框架划分为模块，我们就可以指派擅长该部分的开发者来完成它。从而使开发效率最大化。以开发Web应用为例，模块化带来如下好处：指派熟悉表现层的用户界面开发者负责应用的前端，开发效率会更高；而指派熟悉业务逻辑层的开发者负责应用的中间层和后端，开发效率会更高。同样，对使用应用框架者来说，用的开发者擅长使用框架的用户界面相关模块，而有的开发者擅长使用框架的业务对象。

B：可重用性

代码的可重用性是应用开发中最重要和最令人期待的目标。应用框架能为基于其上构建的应用提供这种可重用性；而且，不仅应用框架的类和代码被重用了，其设计也被重用了，不同的应用通常会包含很多本质上相似的任务，然而，团队中的不同开发者往往都会自己实现一遍。这种重复实现，不仅在重复的代码上不要的浪费了资源，也为以后的维护带来了困难。这是因为，要保证修改的彻底，必须对应用的多出进行重复修改。另外，由于每个开发者的设计方法和使用技术可能不尽相同，这就可能使应用的设计变的很糟糕，为以后带来不可预料的问题。然而，有了应用框架，我们就能将大量重复代码和通用的解决方案从应用层移到框架层。这样一来，开发者编写和维护的重复代码的数量减杀了，开发效率也大幅度的提高了。应用框架是精心设计的组件汇集之处，其中不乏“久经考验”的优秀软件设计方案。开发者并不一定是软件设计专家，但是一旦开始使用框架组件来构建应用，他们就自然而然的在重用优秀的软件设计方法了，比如藏在框架组件背后的设计模式等。

C：可扩展性

可扩展性是往现有的框架中增加自定义功能的能力，它使开发者不仅能够“即拆即用”地使用框架组件，还能够改变组件，以适应特定业务场景的需要。可扩展性是框架的重要特征。每一个业务应用都有独一无二的业务需求，架构和实现。虽然框架本身容纳所有这些具体情况是不可能的，但是，框架采取了支持客户化的思路；这样，不同的业务应用依然能够使用框架的通用功能。同时，开发者通过在框架中使用自定义的业务逻辑，可以自由的按照独一无二的需求裁剪他们的应用。框架本身有了很高的可扩展性，就能适应更多类型的业务应用。然而，在创建框架时，其可扩展性总应根据它将支持的它将支持的应用的设想和上下文来决定。框架的可扩展性越高，使用框架的开发者需要编写的代码就越多，他们需要了解的框架机制细节就越多，这样就会降低开发效率，一个高度可扩展框架的极端例子就是.NET框架，它所支持的应用范围非常广泛。的却，使用.NET框架开发应用几乎没有限制，但结果，你也失去了应用框架能够提供的好处。关键在于，找到你要开发的特定应用中最可能发生变化之处，在那里增加灵活性和可扩展性支持。

D：简单性

          简单性的含义不仅仅是“简单”。简单性指的是一种方法：框架通过封装处理流程的控制逻辑，使它对开发者透明，来简化开发工作。这种封装也是框架和类库的区别之一。类库又许多现成的，供开发者用于构建应用的组件组成。但是，开发者必须理解不同组件之间的关系，并编写处理流程代码把众多组件组织起来。框架则不同，它通过预先把众多组件组织在一起的方式，封装了处理流程的控制逻辑；因此，开发者就不用再编写控制逻辑来组织组件之间的交互了。
类库和框架的这种区别如下图：

由图可知，应用开发者使用类库这种方法时，必须编写管理类库中不同组件实例的控制流程。为此，应用开发者就必须充分理解每个相关组件，以及组件协作所必须的业务逻辑，而使用框架这种方法时，由于大部分处理流程已经被框架管理起来了，所以开发者需要编写的控制代码就非常少了。由于应用框架隐藏了不同组件之间的处理流程，这就免去了开发者编写协调逻辑之苦，也不用经历编写协调代码的学习曲线了。既然处理流程的控制逻辑从应用层移到了应用框架层，那么框架的设计人员就要运用其架构和领域知识，来定义框架内的组件该如何协作；而使用框架的开发者，几乎无须知道框架组件如何协作，就能高小的开发应用。

E:可维护性
        可维护性是业务需求改变之后，其应用便于修改的能力，它是代码重用带来的一个受欢迎的效用。框架组件通常会被多个应用或单个应用中的不同部分共享。只保留一份框架代码库使得应用易于维护，因为当需求改变时，你只需改变一次，应用框架也肯能包含多个层，每一层关于应用要支持的业务都有某写假设。其中，最低层包含了没有任何业务假设的框架组件，它们是框架中最通用的组件；层次越往上，某组件依赖的业务假设越多，因此也对业务需求和业务规则的变化越敏感。每当变化发生时，只有那些业务假设没被打破的层中的组件需要被修改和测试。因此，让框架的不同层包含不同级别的业务知识，能够减少因改变业务需求和业务规则所带来的连锁反应。这也使得维护成本减低，因为只需维护因业务规则改变所影响到的代码。

 

四：没有免费的午餐[应用框架带来的弊端]：

A：应用框架的开发并不廉价：  

        开发应用框架并非易事，为了开发高度可用和可扩展的框架，你需要首先找到合适的人选----业务方面专家，或者软件设计和开发的专家，上述两项技能缺一不可；没有业务知识，就无法开发特定业务领域框架层；应用开发人员要依靠该层弥补他们业务领域知识的欠缺；没有软件技术知识，就无法将框架思想贯彻到具体的框架代码中去，会导致应用开发人员无法重用和扩展这些代码，这个就是应用开发人员和框架开发人员的最大区别。
框架的的设计者必须决定：应用开发者如何从框架提供的服务和架构中获益；如何去抽象应用中特定的通用逻辑，以使开发者通过框架重用这些逻辑；如何在框架的恰当处提供扩展点，以使开发者能插入代码获得特定结果。开发框架的一些工作是很抽象的，并且严重依赖于一个前提：应用开发者将如何使用框架构建应用。
         一开始把所有的问题全部搞清楚是很困难的。因为在设计时只能猜测：最终应用是什么样子，又是如何被构建以解决业务问题的？有的框架组件，最初认为将被应用的多个部分分享，但最终不是如此。有的代码段，可能最初被认为是某一个应用独有的，应该放到应用层，结果却发现被整个应用所共享，需要提取抽象，放到框架层中去。在开始框架以后，新的业务需求或变更了的需求可能导致两种情况：新的框架组件加入，或者现存的框架组件修改。
         所以，为了使框架适应将要在其上开发的应用的需求，框架开发过程要经过一系列的迭代周期开发，所以框架的开发和常规的应用开发类似，需要反复的进行分析，设计，实现和稳定的工作。

B：对应用层程序员的束缚：

         框架提供了一个构建系统所需要的基本架构及功能，协助程序员在快速，不容易出错的情况下研发应用程序。但是更合乎实际情况的说法是：框架框住了程序员的思考路径，强制他们遵循框架所提供的规范来开发程序，避免因个别程序员的程度以及思路的差异，导致研发出的应用程序出现操作界面不协调或流程不一致等错误。框架所提供的一致性特色，也能让主导者为刚入门的程序员设计出一套标准的训练课程，帮助他们尽快进入状态，发挥生产力。
       也就是说，对于整个项目而言是好事，而对应用开发层面的程序员来说确是种束缚，如果程序员的层次比较低或者大局观比较差，就会出现项目开发完了，但是感觉自己的水平增长很少，我想这也就是大多数国人在日本公司呆了几年，然后感觉没学到多少东西的原因吧。但是当你努力的去研读框架的代码和文档的时候，你就进入另外一个境界了。关于研读框架的代码所带来的好处，在优快云最新有一篇文章就是说这个的，大家可以找来读读。

C：用户培训：

        框架的使用者是构建应用的开发者，所以其用户培训就是训练开发者使用应用框架。为了利用框架，开发者必须有足够的应用框架知识，以及如何使用框架进行开发的知识。
但是，学习框架是一个耗时的过程。大家都是用C#做应用开发的，想想Microsoft庞大的MSDN文档学习和查阅就知道了。
        框架天生就不是完整的应用，其中缺少的部分需要开发者编写应用层代码来补充。在应用开发完成以前，对许多开发者来说，框架本身可能不太容易理解，因为框架的每一部分与其他部分的交互关系，并非自始至终都很明显。
        框架中包含很多控制整个框架处理流程所必须的总控代码。尽管框架的目的之一就是把这些复杂的控制逻辑对开发者隐藏起来，但是在培训时候，开发者还是应当理解框架是如何工作的。因为框架中的很多控制逻辑以及类之间的依赖关系，并非直截了当，而且比较复杂，所以理解框架的工作原理并非易事。
        应用框架提供了新的编程模型，它包含了很多开发者陌生的API，服务和配置项。开发者需要花些功夫学习应用框架，才能流畅使用它，最终高效的在其上开发应用。
        尽管学习曲线是要经历的，但我们可以通过完善的文档，以及演示如何在各种场景使用框架的范例，来加快开发者掌握应用框架的速度。对于编程来说，一个范例的效果胜过千言万语。

 

五：如何衡量框架使用与否：

            并非所有的应用都需要在应用框架上构建，很多成功的应用并未使用应用框架。
大可不用的情况：你希望投入有限的费用并快速开发出解决方案，这时可能使用框架节约的成本还没有开发框架投入的成本多。
        相反：也有这种情况，应用框架被多个应用共享，从而总的开发成本显著减少。
        还有：你希望今天在应用框架上投资，以为将来的开发提供一个可扩展和可重用的基础平台。
        总之，就是看应用框架是否有助于你到达到目的的预期目标。
        开发应用框架就象在股市投资：好的投资对你的投资目标有利，而不是看它们今天是否赚钱。

六：题外话：
        可能有人看了上面的描述，要说了，这些可能离我们太遥远了，因为我们是做应用开发的，并不是做框架开发的，其实一切并不遥远。
        程序语言发展到现在，经历了很多种演变：汇编-->结构化语言à基于对象的à面向对象[多继承—>单继承]。从另外一条线走：内存自己释放的-->内存自管理的。
        那么从软件开发的演变来看：没有过程没有类-->只有函数-->既有函数又有对象-->只有对象。然后就是设计模式，重构，一切的一切都是围绕着如何高效的开发，如何减低开发成本，如何使加入团队中的开发人员尽快熟悉业务，熟悉开发流程，如何减低维护成本来的。
        而框架开发是我所知道的最高阶的重用技术，或者说是最高阶的开发境界。虽然我们并不需要有框架开发的能力，但是框架开发的境界还是需要的，因为高屋建瓴，才能够运筹帷幄，决胜千里。
       很多时候你也许会奇怪为什么那些技术大拿，会精通那么多语言，一门技术出现了，他们会很快适应并且精通，因为他们是站在框架的角度去考虑和学习的。
        从软件工程的角度来考虑，如果一个项目应用了框架技术，那么首先开发成本会降低，因为应用是基于框架的，流程一致，那么问题出现也一致，对应的测试也很好做。而且方便做一些通用的代码生成工具或者配置生成工具。项目新人只要熟悉一个小应用，就可以熟悉适应整个大的应用。维护成本也会相应的减低，因为框架一致，所以技术很单一，技术相对弱的就可以维护，而且很轻松。
 

============================================================

对于框架的分层，我找到了两种说法，但是它们之间并不冲突，下面我一一说来。

 

框架解析一：
        刚才我们已经提到，应用框架是个应用的“半成品”，它能作为一个业务应用的起点。基于框架的应用又两层组成：应用层和框架层。框架层可能包含众多组件。这些组件可以被划分为两类：特定领域组件和跨领域组件。下图展示了不同组成部分以及它们之间的关系：

一：框架的分层：

应用中的多个层

二：应用架构解析：

A：业务应用 [Business Application] 层：

       业务应用层代表客户化应用，它由应用开发者负责开发。为了达到待开发的特定应用木的，业务应用层必须实现事无巨细的业务知识，开发人员根据业务分析员描述的详细场景，来构建业务应用层。当业务逻辑和规则发生变化的时候，最可能发生变化的正是业务应用层，特别是当这种变化比较小并已被隔离的时候，更是如此。

B：应用框架 [Application Framework] 层：

       应用框架是应用的半成品，软件架构师负责开发它，作为应用开发者构建业务应用层的基础。应用框架层可以被进一步划分为两层：特定领域框架层和领域框架层。

       B.1：特定领域框架层：

        特定领域框架层由针对特定业务领域的专有组件组成。相对业务应用层而言，特定领域框架层实现的知识，就是特定业务领域的所有应用通用的。而业务应用层的业务知识，就是专门针对某个特殊应用的。
        我们可以把特定领域框架层想象成一个国家的宪法，而把业务应用想象成某个洲或者地方政府的法律。只要和宪法保持一致，一个州可以自由定制适合该州情况的法律。和宪法类似，特定领域层并不规定每个业务应用该怎么构建；它提供一组组件，这些组件封装了特定业务领域的核心业务特征和过程。例如：对于一个在线B2C 业务领域而言，购物车组件就是特定领域框架的组件，该组件负责描述客户选购的商品项，每项的数量和选购时间。不同的在线购物网站可以在不同的场景以不同的方式来使用这个购物车组件，但是都有个共同的特点：都需要一个对象提供诸如客户选购的商品项，每项的数量和选购时间这些信息。
        尽管开发该层的时候，软件架构技能是很重要的，但专业知识对该层的成功尤其关键。
我们期望，特定领域框架层所包含的业务领域知识，比业务应用层的业务知识稳定的多。我们期望，当业务应用层的业务规则发生变化时，特定领域层能够很少变化或者不变化。

B.2：跨领域框架层：

        跨领域框架层由不包含业务领域知识的框架组件组成。因为不包含业务领域知识，所以跨领域框架层能够被多个不同业务领域的应用共享。换言之，跨领域框架层中的组件和服务通用于大多数的应用，而不论该应用是针对哪个业务领域的。
        不同业务领域的应用有很多共同的主题，这些公共主题可以被“打包”成跨领域框架层。
        例如：每一个应用都需要某种管理信息的功能，这些配置信息必须能被应用的不同部分所使用。如果已经有了这样的一个配置服务和架构，则众多不同业务领域的应用就不用投入精力去重复开发了。
再例如，在分布式环境下，一个应用常常需要和另一个系统中的应用通信。所以，一个现成可用的，在不同应用之间传递信息的事件通知服务，将对开放式应用大有好出。所以不难明白，如果能在不同应用中识别出这些公共主题，并进一步开发出相关的服务和组件去满足这些公共需求，我们就能显著提高代码和设计的重用性。
        跨领域框架层的开发者需要具备的条件：开发过很多应用，对软件设计有深入的理解。他们应当知道那些是众多应用中的通用功能。他们不必太了解业务，但他们必须有优秀的面向对象的技能，只有这样，他们开发出的框架，才能让应用层的开发人员很容易地插入业务逻辑，以解决特定应用的问题。
既然跨领域框架层并不包含特定的业务领域知识，就可以把它看作是大部分应用所通用的。所以，改变业务规则和业务需求，并不会影响跨领域框架层。然而，在开发过程中，如果认定出现了新的公共主题，跨领域框架层就会受到影响，因为这个需要在跨领域框架层。

C：基础框架 [Foundation Framework] 层：

基础框架层是一种编程模型，应用框架和业务应用在其上被构建。这一层是由软件供应商开发的。当前最富盛名的基础框架是Sun的Java环境和Microsoft的.NET框架等。基础框架被用来开发五花八门的应用，它并不包含业务领域知识。对基础框架的更改，主要是用于提高性能或者支持新技术的需要。

D：操作系统 [OS ] 层：

操作系统代表操作系统这一层次。它除了提供对CPU，存储器和磁盘这些系统资源的访问以外，还提供了对位于其上所有层的访问。

框架解析二：

一：框架的分层：

        Base FrameWork和Application FrameWork 相当于上面的基础框架 [Foundation Framework] 层
        Domain Application FrameWork相当于上面的应用框架 [Application Framework] 层：

Base FrameWork	API,Runtime
Application FrameWork	MFC,OWL,VCL,JFC,WinForm,ASP.NET
Domain Application FrameWork	进销存/会计用/医疗软件用FrameWork等

二：框架的解析：

A：Base FrameWork：

Base FrameWork层提供了写软件需要的基本功能。比如Windows API,比如JAVA的JRE,.NET的BCL都可以归类到该层级。它所提供的功能通常相当广泛而且丰富，缺点是运用起来不够方便和有效率，优点是具备高度的弹性，程序员可以运用它编写不同领域的应用程序。除了OS之类的软件以外，几乎所有的应用程序都是构建在Base FrameWork之上的。

 

B：Application FrameWork:

        Application FrameWork层是架构在Base FrameWork层之上的，补足其缺点的一种框架，它提供了快速开发应用程序所需要的功能，同时又能有效的隐藏Base FrameWork的复杂性。比如MFC,OWL,VCL,BCL,JAVA的Spring都可归类为Application FrameWork层。
C：Domain  Application FrameWork：

框架开发过程：

一：分析：

        框架开发需要确定框架的范围和目标：
        这个框架的主要功能是什么？
        这个框架将要支持什么类型的业务应用？
        考虑开发者如何在这个框架的基础上开发他们的业务应用？
        这个框架能够支持那些业务领域？
 
        在分析阶段，我们还需要制定出逐步改进框架的跌代计划。我们还需要起草项目计划，并确定每个阶段主要里程碑的时间和文档。

二：设计：

        该阶段有两个任务。首先：对特定领域框架层和跨领域框架层，都要识别出通用点和扩展点，其次，为框架设计架构，它将用作实现阶段的蓝图。
        在设计阶段，也可以创建应用框架原型，然后在其上构建一个样本应用；通过该样本应用测试应用框架原型，有帮于你了解所开发的框架如何用于构建业务应用，并洞察到框架设计中潜在的可改进之处。
三：实现：
        该阶段主要是框架的编码实现阶段。在规定的时间内，开发一个满足需求的框架。
这个阶段大体和常规应用开发一样，区别在框架的单元测试远没有业务应用的单元测试那么直接，因为此时，使用框架的应用甚至还没有创建，所有应用的业务数据也都没有发生。

四：稳定：

稳定阶段是一个迭代周期的最后一个阶段，它的工作集中在测试，修改BUG，开发者反馈，写文档和进行培训。

 

框架开发技术<后补>：

一：框架开发与分层思想：

 框架开发的含义中就提到了：先有框架层，然后在其上搭建应用程序层，所蕴涵的思想就是分层，所以如果没有分层的思想，框架开发就只能流于空想了，所以在这里很有必要提一下为什么要分层？

A：分层的好处：

[企业应用架构模式]中如是说：
       I：在无需过多了解其他层次的基础上，可以把某一层作为一个有机整体来理解。例如：无需知道以太网的工作细节，你照样可以在TCP上构建FTP服务。
       II：可以替换某层的具体实现，只要前后提供的服务相同即可。例如：FTP服务无论是在以太网，PPP上，还是网络运营商使用的任何网络上都无需改变，而且与提供传输电缆的网络运营商无关。
       III：可以将层次间的依赖减到最低。假设网络运营商改变了物理传输系统，但只要IP层不变，FTP服务就可以不改变。
       VI：分层有利于标准化工作。TCP和IP就是关于它们各自层次如何工作的标准。
       V：一旦构建了某一层次，就可以用它为很多上层服务提供支持。因此，TCP/IP同时被FTP,telnet,HTTP使用。否则，所有这些高层协议都必须编写它们各自的底层协议。

 

[.NET企业应用框架]中如是说：
       I：把代码分离到用户界面组件，业务组件以及数据库组件之后，应用程序就能扩展到支持成百上千个用户了。用户数量不多时，你可以把所有的组件都放在一个系统内运行，但随着用户量的增长，你也可以随时把这些组件分布到多个系统中。
       II：如果业务逻辑发生改变，而业务组件是运行在服务器系统上的话，你就不用再给每个客户端系统重新部署应用程序了—你只需要更新服务器系统即可。
       III：你不用再为所有的客户端系统安装和维护数据库驱动程序了—因为只有数据访问组件需要对数据库进行访问（而它很可能只是运行在一台中间层服务器上）；
       VI：多个用户可以共享数据库连接—因为这些连接不是直接由客户端系统直接建立的，而是由一台中间层服务器建立的。
       V：你可以把应用程序划分为不同的部分，以便不同国家和地区的用户通过低速网络也能运行应用程序
       VI：通过把应用程序分解为多个组件，你可以更容易地把开发任务分配给多个开发人员开发。
       VII：你可以在多个应用程序之间重用代码。
B：分层的坏处：
 [企业应用架构模式]中如是说：
        I：层次并不能封装所有东西。有时它会为我们带来级联修改。最经典的例子就是在一个分层设计的企业应用中，如果要增加一个在用户界面上显示的数据域，就必须在数据库中增加相应的字段，还必须在用户界面和数据库之间的每一层做相应的修改。
        II：过多的层次会影响性能。在每一层，一般都会从一种表现形式转换到另一种。不过底层功能的封装通常带来比代价更大的效率提升。例如，可以优化事务控制层，提高其他各层的效率。
 
    注意：分层架构中最困难的问题是决定建立哪些层次以及每一层的职责是什么。
二：框架开发与UML：

三：框架开发技术：

    A：通用点
    B：扩展点
    C：设计模式
    D：重构

四：框架开发方法：

    A：黑盒框架
    B：白盒框架
    C：灰盒框架

框架开发实例讲解<实例>：

====================================