框架和类库的区别

框架？

   框架和类库等概念的出现都是源于人们对复用的渴望。“不要重复发明轮子”，成了软件界的一句经典名言。从最初的单个函数源代码的复用，到面向对象中类的复用（通常以类库的形式体现），再到基于组件编程中二进制组件（.NET中是以IL程序集形式存在的）的复用，人们复用软件的抽象层次越来越高。现在，框架复用是抽象层次的又一提升，框架的复用不仅仅是功能的复用，更是设计的复用。

1．1 框架与类库的区别

   我们先来简单说说什么是类库（Class Library）？望文生义，类库就是一些类的集合，只要我们将一些可以复用的类集中放到一个Library中，我们就可以称其为一个类库。类库中的许多元素（如类、结构、接口、枚举、委托等）之间可能有一些关联，但这些关联通常用于支持一个类概念或接口概念的完整表达。如果我们从一个更高的视角来审视类库，可以发现类库中的一个个“完整的概念”之间是无关的或是关系松散的。

   再来说框架，框架的第一含义是一个骨架，它封装了某领域内处理流程的控制逻辑，所以我们经常说框架是一个半成品的应用。由于领域的种类是如此众多，所以框架必须具有针对性，比如，专门用于解决底层通信的框架，或专门用于医疗领域的框架。框架中也包含了很多元素，但是这些元素之间关系的紧密程度要远远大于类库中元素之间的关系。框架中的所有元素都为了实现一个共同的目标而相互协作。

   没有一个万能的框架可以应用于所有种类的领域和应用，框架的目标性非常强，它专注于解决某一特定领域的问题，并致力于为这一特定领域提供通用的解决方案。

   框架与类库的区别主要表现在以下几个方面：
（1）从结构上说，框架内部是高内聚的，而类库内部则是相对松散的。
（2）框架封装了处理流程的控制逻辑，而类库几乎不涉及任何处理流程和控制逻辑。
   正是由于框架对处理流程的控制逻辑进行了封装，才使得框架成为一个应用的骨架。框架中的处理流程和控制逻辑需要经过精心的设计，因为所有使用了该框架的应用程序都会复用该设计。
（3）框架具有IOC（控制反转）能力，而类库没有。   
   IOC，即俗称的好莱坞模式（Don’t call us, we will call you）。对于类库中的元素来说，通常都是由我们的应用来调用它；而框架具有这种能力――在适当的时候调用我们应用中的逻辑。这种能力是通过框架扩展点（或称为“插槽”）来做到的――具体的应用通过扩展点注入自己的逻辑，而在适当的时候，框架会调用这个扩展点中已注册的逻辑。实际上，.NET中的事件（event）发布、预定机制就是IOC的一个代表性例子。
（4）框架专注于特定领域，而类库却是更通用的。
   框架着力于一个特定领域的解决方案的完整表达，而类库几乎不针对任何特定领域。比如，本书中提到的通信框架只适用于需要在TCP/UDP基础上直接构建通信的应用程序，而像正则表达式这样的类库却可以使用在各种不同的应用中。
（5）框架通常建立在众多类库的基础之上，而类库一般不会依赖于某框架。

1．2 通用框架与应用框架

      如果要对框架进行进一步分类，则可以根据框架针对的领域是否具有通用性而将它们分为通用框架（General Framework）和应用框架（Application Framework）。通用框架可以在不同类型的应用中使用，而应用框架只被使用于某一特定类型的应用中。
      比如，ORM框架NHibernate就是一个通用框架，该框架可以用于所有需要解决O/R映射的各种类型的应用中。而某个金融框架则是一个应用框架，它仅仅被用于金融类型的应用中。
      可以这么说，通用框架所解决的是所有类型的应用都关心的“普遍”问题，而应用框架解决的是某一特定类型的应用关心的问题。所以，如果我们需要将某种类型的应用的核心业务逻辑流程提升到一个框架中，所得到的这个框架就是一个应用框架。与通用框架相比，应用框架需要了解更多目标业务领域内的领域知识。
      在实现具体的应用程序时，可以采用一个应用框架与多个通用框架相结合的方式，这样有利于快速、高质量的应用程序开发。比如，某个金融领域的一个应用，可以采用金融框架作为应用框架来解决与金融业务逻辑相关的问题，采用Nhibernate解决数据访问，采用ESFramework解决应用中各分布式系统之间的通信。 

      下图描述了类库、框架和应用之间的层次关系。

   当然，一个应用也可以完全不采用任何框架，而是直接从最基础的底层API（如.NET Framework）开始构建。对于微型的系统，这种方式或许可行。但对于复杂大型的应用，困难度就可想而知了。

1．3 框架之于应用

   当一个应用系统选定了框架之后，我们需要做的就是在框架提供扩展点的地方添加应用的具体逻辑，也就是使用“血”和“肉”来填充这个骨架从而得到一个“有机体”。
   由于框架通常都是在实践中经过反复使用和检验的，所以质量有一定的保证，这使得我们用更少的时间、更少的编码来实现一个更稳定的系统成为可能。当然，框架也不是“银弹”，它不能解决软件复杂性的根本问题，但是我们却通过它向这个终极的理想目标又迈进了一步。
   有一点需要注意，框架使得我们的系统在有所支撑的同时，它也给出了限制。因为通常当我们确定采用了某一个框架之后，我们就必须在这个框架限制的“框框”之内来构建我们的应用。大多数时候，这不是一个问题，但是如果因为框架的限制而严重影响了我们系统目标的实现的时候，我们就需要考虑是否应该放弃这个框架，或者换一个其它的同类型的框架。

1．4 框架设计

   框架使得我们开发应用的速度更快、质量更高、成本更低，这些好处是不言而喻的。然而，面对万千变化日趋复杂的软件需求，设计和实现一个高度灵活可复用的框架又谈何容易！
   框架源于应用，却又高于应用。
   框架往往是这样产生的：我们拥有了开发某种类型应用的大量经验，我们总结这种类型的应用中共性的东西，将其提炼到一个高的层次中，以备复用。这个“高层次”的东西便是框架的原型。随着我们经验的不断积累，框架也会不断地完善、发展。
   框架是一个实践的产物，而不是在实验室中理论研究出来的。所以设计一个框架最好的方法就是从一个具体的应用开始，以提供同一类型应用的通用解决方案为目标，不断地从具体应用中提炼、萃取框架！然后在应用中使用这个框架，并在使用的过程中不断地修正和完善。
   有一点需要特别注意，正如所有的软件架构设计的要点在于权衡（在这方面有点像艺术），框架的设计也不例外，正如前面提到，框架在为应用提供了一个骨架的同时，也给我们的应用圈定了一个框框，我们只能在这个有限的天地内来发挥。所以，一个好的框架设计应当采用了一个非常恰当的权衡决策，以使框架在为我们应用提供强大支持的同时，而又对我们的应用作更少的限制。权衡，从来就不是一件简单的事情，但是有很多框架设计的经验可以供我们参考。

1.4.1 框架设计经验、原则

（1）框架不要为应用做过多的假设！     

   关于框架为应用做过多的假设，一个非常具体的现象就是，框架越俎代庖，把本来是应用要做的事情揽过来自己做。这是一种典型的吃力不讨好的做法。框架越俎代庖，也许会使得某一个具体应用的开发变得简单，却会给其它更多想使用该框架的应用增加了本没有必要的束缚和负担。

（2）使用接口，保证框架提供的所有重要实现都是可以被替换的。

框架终究不是应用，所以框架无法考虑所有应用的具体情况，保证所有重要的组件的实现都是可以被替换的，这一点非常重要，它使得应用可以根据当前的实际情况来替换掉框架提供的部分组件的默认实现。使用接口来定义框架中各个组件及组件间的联系，将提高框架的可复用性。

（3）框架应当简洁、一致、且目标集中。

框架应当简洁，不要包含那些对框架目标来说无关紧要的东西，保证框架中的每个组件的存在都是为了支持框架目标的实现。包含过多无谓的元素（类、接口、枚举等），会使框架变得难以理解，尝试将这些对于框架核心目标不太重要的元素转移到类库中，可以使得框架更清晰、目标更集中。

（4）提供一个常用的骨架，但是不要固定骨架的结构，使骨架也是可以组装的。

比如说，如果是针对某种业务处理的框架，那么框架不应该只提供一套不可变更的业务处理流程，而是应该将处理流程“单步”化，使得各个步骤是可以重新组装的，如此一来，应用便可以根据实际情况来改变框架默认的处理流程。这种框架的可定制化能力可以极大地提高框架的可复用性。

（5）不断地重构框架。

   如果说设计和实现一个高质量的框架有什么秘诀？答案只有一个，重构、不断地重构。重构框架的实现代码、甚至重构框架的设计。重构的驱动力源于几个方面，比如对要解决的本质问题有了更清晰准备的认识，在使用框架的时候发现某些组件职责不明确、难以使用，框架的层次结构不够清晰等。

1.4.2 如何称得上一个优秀的框架？

      一个优秀框架的最主要的特点是：简单。这种简单性不是轻而易举就可以获得的，正如优秀的框架不是一蹴而就的，达到这种简单性需要对框架不断地抽丝、不断地提炼和完善。简单的真正原因在于它抓住了要解决的问题的本质。一个优秀的框架通常都具有如下特点：

（1）清晰的、简洁的、一致的。    

      “清晰”指的是框架的结构是清晰的、框架的层次是清晰明朗的、框架中各个类和组件的职责是清晰明确的。

“简洁”指的是框架中没有无关紧要多余的元素，而且各个类和组件的职责目标是非常集中的，这正是“高内聚、低耦合”设计原则的体现。

“一致”通常会带来这样的好处，框架的使用者在熟悉了框架的一部分后，会非常容易地理解框架的另一部分。“一致”通常体现在命名的规则一致、命名的含义一致、组件的装配方式和使用方式一致等。

（2）易于使用的

      只有易于使用的框架才会走得更远。

   正是因为易于使用，框架使用者们才有可能试用这个框架，在试用满意后才有可能决定采用这个框架。一个框架功能即使再强大，如果难以使用，那么框架使用者们很可能根本就不会有试用这个框架的念头。

框架的生命力源于框架一直在不断地完善和发展，如果没有人使用这个框架，这个框架便没有了发展和完善的源动力。正如友好的用户界面是优秀应用程序不可或缺的重要部分，易于使用也是优秀框架的一个重要特性。

（3）高度可扩展的、灵活的

      框架通过高度可扩展性来应对应用程序的万千变化。

      没有任何一个框架可以预料所有应用的需求，万能的框架是不存在的。企图设计、实现一个万能框架的想法是荒诞的。框架必须具有“以不变应万变”的能力，框架可以通过为应用预留恰当的、足够的扩展点来做到这一点。

      框架的灵活体现在框架可以根据不同的应用进行不同的组装和配置，就像框架是专门为当前的应用所订制的一样。

（4）轻量的

      “轻量”，说的通俗点，就是只为自己需要使用的服务付费，而不需要为自己不需要的服务买单。一个重量级的框架有一个很明显的特征就是，如果你需要一套完整的套餐服务，那是没有问题的，框架可以很好的满足你；但是，如果你只需要这份套餐中的一小块点心，对不起，框架仍然会强加一个完整的套餐给你，你必须付一整份套餐的费用。
   优秀的框架应当支持使用者“按需所取”的原则，框架使用者可以随意“点菜”进行组装来满足自己的需求。

（5）弱侵入性的

      所谓“弱侵入性”，采用了框架的应用程序可以尽可能的以普通的方式来编写应用逻辑，而不必为了适应框架不得不使用一些特殊的手法。

   这可能有点难以理解，我们可以举个例子来简单说明。在.NET中，实现AOP（面向方面编程）机制的两种主要方式是使用Proxy和动态代理。使用Proxy实现的AOP框架通常要求那些需要使用AOP截获功能的类必须继承自ContexBoundObject；而采用动态代理实现的AOP框架则没有任何如此侵入性的要求，我们仍可以以最普通的方式来编写应用逻辑类，这类框架会在运行时根据配置动态地生成目标对象的代理对象来实现AOP截获。所以我们可以说，采用动态代理方式实现的AOP框架相比采用Proxy实现的AOP框架，具有更弱的侵入性。

   弱侵入性意味着框架对应用逻辑的干扰更少，由于应用逻辑类都是普通的类，这非常方便应用逻辑在另外一个程序中复用，而另外的程序可能采用了一个完全不同的框架。