库执行特定的、定义良好的操作。

框架是一个骨架，应用程序通过填充骨架来定义操作的“肉”。框架仍然有代码来连接各个部分，但最重要的工作是由应用程序完成的。

库的例子:网络协议、压缩、图像处理、字符串实用程序、正则表达式计算、数学。操作是独立的。

框架示例:Web应用程序系统，插件管理器，GUI系统。框架定义概念，而应用程序定义最终用户关心的基本功能。

正如我一直描述的那样:

图书馆是一个工具。

框架是一种生活方式。

你可以使用任何微小的部分来帮助你。一个你必须将整个项目投入其中的框架。

我认为你很好地阐述了其中的区别:框架提供了一个我们工作的框架……不知何故，它比简单的库更“有约束”。 框架还应该为一组库添加一致性。

库vs框架

Martin Fowler - InversionOfControl

库和框架是你的代码的外部代码。它可以是文件(例如。jar)，系统代码(操作系统的一部分)等。

库是一组有用的代码。主要关注你的代码。库解决的任务范围很窄。例如，实用程序，排序，模块化

your code ->(has) Library API

框架或控制反转(IoC)容器[About]是更多的东西。框架解决了广泛的任务(特定于领域)，你委派这个任务给框架。IoC——你的代码依赖于框架逻辑、事件…因此框架会调用你的代码。它迫使你的代码坚持它的规则(实现/扩展协议/接口/契约)，传递lambdas…例如-测试，GUI, DI框架…

your code ->(has) and ->(implements) Framework API

[iOS Library vs Framework]

[DIP vs DI vs IoC]

实际上，这取决于你给术语下什么定义。可能有很多不同的定义。

我认为下面的解释是基于我认为这个术语指的是什么:

确定的图书馆

确定性库保存的函数是基于A)函数输入或b)在函数调用之间以某种方式维护的状态确定的。

如果将逻辑依赖注入确定性库，则该逻辑必须符合具体的规范，以便库的输出不受影响。

示例:一个碰撞检测库，由于某种原因依赖于排序函数来帮助这些计算。这个排序函数可以配置为优化目的(例如通过依赖注入，编译时链接等)，但必须始终符合相同的输入/输出映射，以便库本身保持确定性。

非命定论的图书馆

一个非确定性库可以通过与它以某种方式访问的其他外部非确定性库通信来保存非确定性函数。

我通常将不确定性库称为服务。

示例:依赖于随机数字生成器服务来洗牌的扑克库。这可能是一个不好的例子，因为出于架构的目的，我们应该将这个库的不确定性方面推到外部。相反，通过采用预先洗牌的牌组，扑克库可以变得具有确定性和单元可测试性，现在这个库的用户有责任随机洗牌，如果他们愿意的话。

框架

框架介于确定性库和非确定性库之间。

任何依赖注入框架的逻辑在该函数实例的生命周期内都必须是确定的，但是不同逻辑的不同函数实例可以被注入到框架函数的单独执行中。

Example: Functions that operate on lists such as map, filter, sort, reduce, that expect to take in functions that are deterministic but can have varying logic for different executions. Note that this requirement only exists if these list operations advertise themselves as deterministic. In most languages, list operations wouldn't have this constraint. The core logic of such frameworks are deterministic, but are allowed to accept indeterministic logic at the risk of the user. This is generally a messy scenario to deal with, because output can vary widely due to implementation details of the framework.

库——任何一组类或组件，只要客户端认为合适，就可以使用它们来完成某个任务。 框架——要求你将某些指导方针“插件”到比你更大的东西中。您只需以一种已发布的必需方式提供特定于您的应用程序/需求的部分，以便“框架可以使您的生活变得轻松”。