フレームワークとライブラリの違いは何ですか？
framework と library の違いは何ですか？
私はいつもライブラリを特定の問題や特定の分野のアプリケーション開発（すなわちデータベースアクセス）を解決することに焦点を合わせたオブジェクトと関数のセットとして考えていました。一方で、フレームワークは特定の方法論（すなわちMVC）を中心としたライブラリの集まりであり、アプリケーション開発のあらゆる分野を網羅しています。
実際にこれらの用語はそれらが使用されている文脈に応じて多くの異なることを意味することができます。
たとえば、Mac OS Xでは、フレームワークは単なるライブラリであり、バンドルにまとめられています。バンドル内には実際の動的ライブラリ（libWhatever.dylib）があります。裸のライブラリとMac上のフレームワークとの違いは、フレームワークはライブラリの複数の異なるバージョンを含むことができるということです。追加のリソース（画像、ローカライズされた文字列、XMLデータファイル、UIオブジェクトなど）を含めることができ、フレームワークが一般に公開されていない限り、ライブラリを使用するために必要な.hファイルが含まれています。
したがって、アプリケーション内でライブラリを使用するために必要なものが1つのパッケージ内にすべて含まれています（ライブラリのドキュメントに従って自分で記述しない限り、.hファイルのないC/C++/Objective-Cライブラリはほとんど役に立ちません）。移動するファイルの集まり（MacバンドルはUnixレベルでは単なるディレクトリですが、UIでは1つのファイルとして扱います。JavaファイルにJARファイルがあるのと同じように、クリックすると通常は表示されません）明示的にコンテンツを表示することを選択しない限り、中身は何です。
ウィキペディアはフレームワークを「流行語」と呼んでいます。それはソフトウェアフレームワークを次のように定義します。
ソフトウェアフレームワークは、ソフトウェアシステム（またはサブシステム）の再利用可能な設計です。ソフトウェアフレームワークは、サポートプロジェクト、コードライブラリ、スクリプト言語、またはソフトウェアプロジェクトのさまざまなコンポーネントの開発および接着を支援する他のソフトウェアを含み得る。フレームワークのさまざまな部分がAPIを通じて公開される可能性があります。
ですから私は、図書館はそれだけの「図書館」だと思います。それはオブジェクト/関数/メソッド（あなたの言語に依存します）の集まりであり、あなたのアプリケーションはそれに対して「リンク」しているので、オブジェクト/関数/メソッドを使うことができます。これは基本的に、通常は複数のアプリケーションで共有できる再利用可能なコードを含むファイルです（同じコードを何度も書く必要はありません）。
フレームワークは、アプリケーション開発で使用するすべてのものになります。ライブラリ、多数のライブラリの集まり、スクリプトの集まり、またはアプリケーションを作成するために必要なソフトウェアのどれでもかまいません。フレームワークは非常に曖昧な用語です。
これはトピック " Library vs. Framework "に関する何人かの男についての記事です。私は個人的にこの記事は議論の余地があると思います。彼がそこで言っていることは間違っていません、しかし、彼はただフレームワークの複数の定義のうちの1つを選んで、それをライブラリの古典的な定義と比較しています。例えば。彼はあなたがサブクラス化のためのフレームワークを必要としていると言います。本当に？オブジェクトをライブラリ内で定義し、それに対してリンクし、コード内でサブクラス化することができます。そのための「フレームワーク」がどうして必要なのかわかりません。ある意味で、彼はむしろフレームワークという用語が今日どのように使われているかを説明しています。私が前に言ったように、それは単なる誇大宣伝の言葉です。いくつかの会社はただ普通のライブラリを（どんな意味でも古典的なライブラリとして）リリースし、それをより派手に聞こえるのでそれを「フレームワーク」と呼ぶ。
library は、特定の明確に定義された操作を実行します。
framework は、スケルトンを埋めることによってアプリケーションが操作の「重要」を定義するスケルトンです。スケルトンには、パーツをリンクするコードがまだありますが、最も重要な作業はアプリケーションによって行われます。
ライブラリの例： ネットワークプロトコル、圧縮、画像操作、文字列ユーティリティ、正規表現評価、数学。操作は自己完結型です。
フレームワークの例： Webアプリケーションシステム、プラグインマネージャ、GUIシステム。フレームワークは概念を定義しますが、アプリケーションはエンドユーザーが気にする基本的な機能を定義します。
主な違いは、フレームワークが「 Hollywood原則 」、つまり「電話しないでください、電話する」としていることです。
によると マーティンファウラー ：
library は基本的にあなたが呼ぶことができる関数の集合です。最近では通常クラスにまとめられています。各呼び出しはいくつかの作業を行い、クライアントに制御を返します。
framework は、より多くのビヘイビアが組み込まれた、抽象的なデザインを体現しています。それを使用するには、サブクラス化または独自のクラスをプラグインすることによって、フレームワークのさまざまな場所にビヘイビアを挿入する必要があります。フレームワークのコードはこれらの時点であなたのコードを呼び出します。
としょうかん：
コレクションのルーチン（関数型プログラミング）またはクラス定義（オブジェクト指向プログラミング）です。背後にある理由は、単純にコード再利用です。つまり、他の開発者によって既に作成されたコードを取得します。通常、クラスまたはルーチンはドメイン固有の領域の特定の操作を定義します。たとえば、開発者がアルゴリズムの動作方法の実装をやり直さずに関数を呼び出すことができる数学のライブラリがいくつかあります。
フレームワーク：
フレームワークでは、すべての制御フローがすでに存在し、事前定義されたホワイトスポットがたくさんありますする必要がありますコードを入力。通常、フレームワークはより複雑です。 スケルトンの定義アプリケーションは、スケルトンを埋めるために独自の機能を定義します。このようにして、適切なときにフレームワークによってコードが呼び出されます。利点は、開発者が設計の良し悪しを気にする必要がなく、ドメイン固有の機能を実装するだけでよいことです。
ライブラリ、フレームワーク、およびコード画像表現：
KeyDifference：
ライブラリとフレームワークの重要な違いは、“ Inversion of Control”です。ライブラリからメソッドを呼び出すときは、制御できます。しかし、フレームワークでは、コントロールが逆になります：フレームワークがあなたを呼び出します。 ソース
関係：
どちらもAPIを定義しており、プログラマが使用するために使用されます。これらをまとめると、ライブラリはアプリケーションの特定の機能、フレームワークはアプリケーションのスケルトン、APIはそれらをまとめるコネクタと考えることができます。通常、典型的な開発プロセスはフレームワークから始まり、APIを介してライブラリで定義された関数に入力します。
あなたは図書館を呼びます。
フレームワークはあなたを呼び出します。
図書館助け
足場が痛い
たくさんの涙
私はいつもそれを説明したように：
図書館は道具です。
フレームワークは生き方です。
どんな小さな部分でも役立つライブラリを使用できます。プロジェクト全体をコミットする必要があるフレームワーク。
私はCohensの回答が好きですが、より技術的な定義は次のとおりです。あなたのコードはライブラリを呼び出します。 フレームワークがあなたのコードを呼び出します 。たとえば、GUIフレームワークはイベントハンドラを通してコードを呼び出します。 Webフレームワークは、いくつかの要求 - 応答モデルを通してあなたのコードを呼び出します。
これは 制御の逆転とも呼ばれます - 突然フレームワークは、ライブラリの場合とは逆に、コードをいつ、どのように実行するかを決定します。つまり、フレームワークは、コードをどのように構成しなければならないかに、より大きな影響を与えます。
Web開発者の観点から：
ライブラリは他のライブラリと簡単に交換できます。しかしフレームワークはできません。
あなたがjqueryの日付ピッカーライブラリが好きではない場合は、ブートストラップ日付ピッカーやpickadateなどの他の日付ピッカーに置き換えることができます。
自分の製品を構築したAngularJSが気に入らない場合は、他のフレームワークに置き換えることはできません。コードベース全体を書き直す必要があります。
主に図書館はフレームワークと比較して非常に少ない学習曲線しか取りません。例：underscore.jsはライブラリ、Ember.jsはフレームワークです。
この定義を見た場所を忘れてしまいましたが、かなりいいと思います。
ライブラリはあなたがあなたのコードから呼び出すモジュールであり、フレームワークはあなたのコードを呼び出すモジュールです。
これが私の考えです（そして他人によって合理化されているのを見ました）。
ライブラリはあなたのコードに含まれるものです。そしてフレームワークはあなたのアプリケーションのためのコンテナです。
フレームワークは異なるライブラリから作ることができます。例を見てみましょう。
魚のカレーを作りたいとしましょう。それならあなたは oil 、 spices そして他の utilities のような成分が必要です。 fish も必要です（これはあなたの料理を準備するためのあなたのベースです）（これはあなたのアプリケーションのデータです）。すべての成分をまとめてframeworkと呼びました。今度はあなたの魚のカレーをあなたの最終製品であるためにそれらを一つずつまたは組み合わせて使用するつもりです。 Webフレームワーク と比較すると、 underscore.js 、 bootstrap.css 、 bootstrap.js 、 と比較できます。 fontawesome 、 AngularJS など。例として、 Twitter Bootstrap v.35 。
さて、あなたがたった一つの成分だけを考えれば、例えば oil のように。あなたが望む油を使用することはできません。それはそれがあなたの魚を駄目にするでしょう（データ）。 オリーブオイル しか使えません。 underscore.js と比較してください。どのブランドのオイルを使いたいのかはあなた次第です。 アメリカンオリーブオイル （underscore.js）または インディアンオリーブオイル （lodash.js）で作った料理もあります。これはあなたのアプリケーションの味を変えるだけです。それらはほとんど同じ目的を果たすので、それらの使用は開発者の好みに依存し、それらは容易に交換可能です。
Framework ：あなたのアプリケーションに固有のプロパティと振る舞いを提供するライブラリの集まり。 （全成分）
Library ：あなたのデータにユニークなプロパティと振る舞いを提供する明確に定義された命令のセット。 （魚油）
プラグイン ：ライブラリ（ui-router - > AngularJS）または組み合わせた多くのライブラリ（date-picker - > bootstrap.css + jQuery）のためのユーティリティビルドで、プラグインは期待どおりに動作しない可能性があります。
P.S AngularJSはMVCフレームワークですが、JavaScriptライブラリです。私は、Libraryはネイティブテクノロジ（この場合はJavaScript）のデフォルトの動作を拡張すると考えています。
これはJoel Spolskyによる 苦い記事にリンクされています しかし、ツールボックス、ライブラリ、フレームワークなどの間の良い区別を含んでいます。
ライブラリは狭い範囲の目的のために機能を実装していますが、フレームワークはより広範囲の機能をサポートするライブラリの集まりです。たとえば、ライブラリSystem.Drawing.dllは描画機能を処理しますが、.NET Framework全体の一部にすぎません。
ライブラリ - クライアントが特定のタスクを実行するのに適していると見なすことができるクラスまたはコンポーネントのセット。
フレームワーク - あなたよりも大きなものに「プラグイン」するためのあなたのための特定のガイドラインを強制します。あなたはあなたのアプリケーション/要求に特有の部分を公表された要求された方法で単に提供するので、 'framweworkはあなたの人生を容易にすることができます'
ライブラリは使いやすさと効率のためです。たとえば、Zendライブラリは、明確に定義されたクラスと関数によってさまざまなタスクを実行するのに役立ちます。フレームワークとは、通常MVC（Model）のような解決策-view-controller） （参照） 。 MVCのようにタスクを分散するための明確に定義されたシステムです。モデルにはデータベース側が含まれ、ビューはUIインターフェイス用、そしてコントローラはビジネスロジック用です。
フレームワークは、私たちが作業を行うためのフレームを提供します。どういうわけか、それは単純なライブラリよりも「制約が強い」ということです。
フレームワークはまた、ライブラリのセットに一貫性を追加することになっています。
ライブラリは、目標を達成するための一連のユーティリティ（ソケット、暗号化など）だと思います。フレームワークはライブラリ+ RUNTIME EINVIRONNEMENTです。たとえば、ASP.NETはフレームワークです。HTTP要求の受け入れ、ページオブジェクトの作成、イベントイベントの呼び出しなどを行います。現在のリクエスト！
とにかく、とても興味をそそる質問です！
私はこの答えの出所を覚えていません（私はそれをインターネットの.pptで見つけたと思います）、しかし答えは非常に簡単です。
ライブラリとフレームワークは、アプリケーションで使用でき、特定の「問題」を解決するのに役立つ、一連のクラス、モジュール、コード（プログラミング言語によって異なります）です。
その問題は、アプリケーション内のログやデバッグ情報、チャートの描画、特定のファイル形式（html、pdf、xls）の作成、データベースへの接続、アプリケーションの一部の作成、アプリケーション全体またはアプリケーションに適用されるコードなどです。 デザインパターン 。
これらすべての問題を解決するためのフレームワークまたはライブラリを持つことができます。通常、フレームワークは、より複雑で大きな問題を解決するのに役立ちますが、両者の主な違いではありません。
ライブラリとフレームワークの主な違いは、それら自身のコード間の依存関係です。つまり、フレームワークを使用するには、FWのほとんどすべてのクラス、モジュール、またはコードを使用する必要があります。自分のアプリケーションでlib内の1つまたは少数のクラス、モジュール、またはコードを使用する
つまり、フレームワークが、例えばあなたが使用する必要があるアプリでそのフレームワークを使用するために50のクラスを持っているなら、あなたのコードの中に10-15以上のクラスがあると言いましょう。クラス（そのクラスのオブジェクト）は、フレームワーク内の他のクラスのメソッドに対する入力/パラメータです。 .NET Framework、Spring、またはその他のMVCフレームワークを参照してください。
しかし、たとえばログライブラリでは、コードにLogクラスを使用するだけでよく、ログの問題を解決するのに役立ちます。つまり、ログライブラリには、クラスのようにそれ以上のクラスがないという意味ではありません。ファイルを処理したり、画面出力を処理したり、さらにはデータベースを処理したりしますが、コード内でそのクラスに触れたり使用したりすることは決してありません。それが、フレームワークではなくライブラリーである理由です。
また、フレームワークとライブラリよりも多くのカテゴリがありますが、それは話題になりません。
library は他のコードで再利用するためにコンパイルされた自己完結型のものなら何でもかまいませんが、文字通りその内容に制限はありません。
一方、 framework は、あなたの例であるMVCのように、アプリケーション開発の特定の分野で使用するためのさまざまな機能を持つことが期待されています。