图

如果你是一个视觉学习者，下面的图表会让你更清楚:

(学分:http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks)

图

如果你是一个视觉学习者，下面的图表会让你更清楚:

(学分:http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks)

框架:安装在你的机器上，允许你与它交互。没有这个框架，你就不能向你的机器发送编程命令

库:旨在解决某一问题(或同一类别的若干问题)

工具包:许多代码片段的集合，可以在多个问题上解决多个问题(就像工具箱一样)

Martin Fowler在他关于反转控制的文章中讨论了库和框架之间的区别:

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

总结一下:你的代码调用一个库，而框架调用你的代码。

库和框架之间最重要的区别，实际上是定义性的区别是控制反转。

这是什么意思?好吧，这意味着当你打电话给图书馆时，你是在控制。但是对于框架，控件是反向的:框架调用您。(这就是所谓的好莱坞原则:不要给我们打电话，我们会给你打电话。)这就是框架的定义。如果它没有控制反转，它就不是一个框架。(我在看你，.NET!)

基本上，所有的控制流都已经在框架中，只有一堆预定义的白点，您可以用您的代码填写。

另一方面，库是您可以调用的功能的集合。

I don't know if the term toolkit is really well defined. Just the word "kit" seems to suggest some kind of modularity, i.e. a set of independent libraries that you can pick and choose from. What, then, makes a toolkit different from just a bunch of independent libraries? Integration: if you just have a bunch of independent libraries, there is no guarantee that they will work well together, whereas the libraries in a toolkit have been designed to work well together – you just don't have to use all of them.

但这只是我对这个术语的解释。与定义良好的库和框架不同，我不认为工具包有一个被广泛接受的定义。

Others have noted that .net may be both a framework and a library and a toolkit depending on which part you use but perhaps an example helps. Entity Framework for dealing with databases is a part of .net that does use the inversion of control pattern. You let it know your models it figures out what to do with them. As a programmer it requires you to understand "the mind of the framework", or more realistically the mind of the designer and what they are going to do with your inputs. datareader and related calls, on the other hand, are simply a tool to go get or put data to and from table/view and make it available to you. It would never understand how to take a parent child relationship and translate it from object to relational, you'd use multiple tools to do that. But you would have much more control on how that data was stored, when, transactions, etc.