转自 http://www.cnblogs.com/daxnet/archive/2009/02/07/1686994.html
很多IT行业的读者，如果有过一些面试经验的，都会被问到一个经典问题：什么是类库？什么是框架？两者有什么关系？我语文不好，要我用一句话去概括这个问题，恐怕也有点难度。就在此多花点笔墨，多写几句吧。
类库首先要谈到面向对象。为什么要面向对象？因为对象与其之间的关系能够客观地描述现实生活中的事物及其之间的关系。现实生活中的事物有如下特点：不同种类的事物，有着不同的属性，也有不同的行为。各种类的事物之间、同种类的事物之间，又多少有些关系。不仅如此，事物与事物之间需要通信，也就是信息交流。显然，传统的面向过程的设计思想无法很好的描述这些现实问题。
为了能够面向对象，我们就把多种事物进行种类抽象，抽象出来的东西形成“类”。各个事物种类之间的关系使用类之间的关系进行表述，这样就形成一张类的关系网络，也就是常说的类库。
常见的类库有：MFC，估计也是大家最熟悉的了；还有VCL，它有两个版本，VCL for C++和VCL for PASCAL的。这两种类库都是非常经典的。此外还有标准C++的STL。在进行软件开发的过程中，或许我们会觉得，即使有着丰富的类库支持，也无法使我们大幅度提高开发效率：我们仍然需要花费大量的精力在基于类库的基础上开发着各种能够重用或者再也无法重用的权限管理模块、实时编译系统、服务器调度策略等等。软件开发过程一度陷入僵局。
框架在讨论什么是“类库”的时候，我们引出了一个棘手的问题，即使有了类库支持，软件开发也不是一件容易的事情。开发出来的模块、系统如果能够重用那还好说，但如果不能重用，那简直就是一堆废铁，软件开发效率没有得到任何改善。
为此，人们针对不同的应用系统，在基于某一类库的基础上，开发出一套特定的框架，框架中包含了应用系统中的“不变因素”，并为“可变因素”留出位置，今后只需要在“可变因素”的位置上部署功能模块，就可以实现不同的应用系统需求。
举例来说，对于图书管理系统、门市销售系统这些小型MIS系统而言，虽然服务的业务领域不同，业务流程也有很大区别，但是，这些系统都需要有用户管理、权限设置、报表输出、查询界面等基础模块。假如有一套框架能够提供这部分功能，那么在进行进一步的系统开发时，就可以大大提高开发效率。
由此可见，框架是一种半成品，也可以看成是软件核心实体（业务实体）的运行环境，它为软件系统提供了各种服务，脱离业务实体而独立存在的框架是无法独立运行的，一点意义都没有。
常见的框架有：.NET Framework、基于.NET Framework上的DotNetNuke、NHibernate、NUnit，基于NHibernate上的Castle ActiveRecord、Microsoft Dynamics AX ERP系统、各种操作系统等。
日常生活中，框架也无处不在，最典型的就是我们平常玩的游戏机，它本身就是一个框架，没有安插游戏卡或者游戏光盘的时候，一点意义都没有，它为游戏提供了运行环境，不同的游戏卡带中包含了不同的游戏内容
模式模式的范围很大。模式分为设计模式、体系结构模式和惯用法[POSA1]。正如唐俊所说，模式是实践经验的总结，也是一种设计思想的表述形式。在对待模式的态度上，我认为我们不应该抱着学习的态度，而应该抱着“了解”的态度。因为它是经验的总结，不是靠读书学习就能得到的东西。“在做软件设计的时候，每个人都想使用某种模式来提高软件的韧度，却不是每个人都知道，在他的设计中，已经采用了这种模式”，谈不谈模式其实都无所谓，只要你能说出你所设计的系统到底好在什么地方。
模式贯穿于类库中，更多的是设计模式，例如，其中的模版方法（Template Method）模式应用非常广泛。模式贯穿于框架中，更多的是体系结构模式，例如分层模式、Broker模式等。模式为设计人员解决现实问题提供了经验参考，它更不可能是可以直接拿来使用的代码。有时候，解决某个问题需要多种模式的配合，比如在实现ORM时，分层、桥、虚代理、模版方法等各种模式都会被涉及到。
模式贯穿于各行各业，建筑有建筑模式、软件设计有设计模式、体系结构模式，商业运作有商业模式、盈利模式。我们的确应该正视模式的重要作用，而不要将其当作是一种炫耀自己的手段。
