フレームワークとライブラリの概念の出現はすべて再利用のための人々の欲望のためです。「車輪の再発明しないでください」、ソフトウェア業界は、古典的な格言になっています。最初の1つのソースコードの多重化機能からコンポーネントプログラムバイナリ成分に基づいて、オブジェクト指向のクラス（典型的にはライブラリの形で具現化）多重化、及びに（IL .NETアセンブリの存在は、の形です）再利用、それはソフトウェアの再利用の抽象化のレベルが増加しているです。さて、抽象化のフレーム多重化レベルは別のアップグレード、多重化だけではなく、フレームの多重化機能である、それは再利用のために設計されています。
1.1フレームワーククラスライブラリとの違い
我々は最初のライブラリ（クラスライブラリ）であるかについての簡単な話を取りますか？名前が示す、ライブラリがいる限り、我々は図書館に焦点を当てた授業の一部を再利用できるよう、私たちは図書館にそれを呼び出すことができ、クラスのいくつかのコレクションです。そこ（等クラス、構造、インタフェース、列挙、信託等）ライブラリの要素数との間の何らかの相関関係であってもよいが、これらの関連付けは、典型的には、クラスインターフェースの概念や概念の完全な表現をサポートするために使用されます。私たちは図書館で見て高い視点からであれば、あなたは内のライブラリ間の無関係なまたは緩やかな関係であることが判明することができる「完全な概念。」
その後のフレームについて、最初のフレームは技術の処理フロー内の制御ロジックをカプセル化し、スケルトンの意味であり、私たちはしばしば半製品は、アプリケーションフレームワークであると言います。タイプフィールドに応じて、そう多数である、フレームワークは、例えば、対処するように設計された基盤となる通信フレームワーク、フレームや特殊医療分野を対象とする必要があります。フレームワークはまた、多くの要素が含まれていますが、これらの要素間の関係の近さは、ライブラリ要素間の関係よりもはるかに大きいです。フレームワークのすべての要素は、共通の目標と相互協力を達成することです。
ユニバーサルフレームワークは、フィールドやアプリケーションのすべての種類に適用することができないが、対象のフレームワークは、それが特定の領域で問題を解決するに焦点を当てて、非常に強力であり、この特定の領域のための一般的なソリューションを提供することを約束しています。
フレームと以下の点でライブラリとの間の主な違いは：
（1）構造から、内部ライブラリは比較的緩い中に内部フレームは、高い凝集力であることを特徴とします。
（2）フレームをカプセル化プロセスのフロー制御ロジック、およびプロセスは、任意のライブラリがほとんど流れ及び制御ロジック伴いません。
フレームは、制御ロジックの処理フローであるので、そのようなアプリケーションの唯一の骨格フレームワークこと、カプセル化されます。プロセスフローおよび制御ロジックフレームワークは、すべてのアプリケーションがフレームの多重化設計を使用するように注意深く設計が必要です。
（3）フレームIOC（制御の反転）能力を有する、ないライブラリ。
IOC、一般的にハリウッドのモデルとして知られている（お電話しないでください、私たちはしますあなたを呼び出します）。要素のライブラリーのために、それはそれを呼び出すために私たちのアプリケーションでは通常であり、この能力を有するフレームは-適切な時期に私たちのアプリケーションロジックを呼び出します。ポイントを拡張することによって、独自のロジックに特定のアプリケーション、および適切な時間に、フレームワークは、登録され、この拡張ポイントを呼び出す-この機能は、実行するために、フレームワークの拡張ポイント（または「スロット」）を介して行われロジック。実際には、.NETのイベント（イベント）放出、所定の機構の代表的な例は、IOCあります。
（4）フレームの特定の領域に集中するが、それは、より一般的なクラスライブラリです。
完全な発現カセットソリューションの特定の領域に焦点を当てますが、任意の特定の領域のためのほとんどのライブラリ。例えば、通信フレームワークを使用すると、TCP / UDPベースで直接通信するアプリケーション、およびライブラリなどの正規表現を構築する必要がある場合にのみ、この本の中で言及したが、異なる様々な用途に使用することができます。
（5）フレームは、典型的には、ライブラリーの数に基づいており、ライブラリーは、一般に、単一のフレームに依存しません。
一般的なフレームワークとアプリケーションフレームワーク1.2
あなたは、さらにフレームを分類したい場合は、フレームは、汎用性のための技術に係るとも彼らは共通のフレームワーク（一般的な枠組み）とアプリケーションフレームワーク（アプリケーションフレームワーク）に分類されているかどうか。一般的なフレームワークは、アプリケーションの異なるタイプで使用することができ、アプリケーション・フレームワークは、アプリケーションの特定のタイプのために使用されます。
例えば、ORMフレームNHibernateは、一般的なフレームワークであるアプリケーションのすべてのタイプのために使用することができるO / Rマッピングさに対処する必要があります。そして、金融アプリケーションフレームワークは、アプリケーションの種類の資金を調達するためにのみ使用され、フレームワークです。
いわば、アドレスへの一般的なフレームワークは、アプリケーションのすべてのタイプの「ユニバーサル」の問題が懸念されており、問題を解決するためのアプリケーションフレームワークは、当該アプリケーションの特定のタイプです。私たちは、コアアプリケーションのいくつかのタイプの必要がある場合に、ビジネスロジック次のフレームへの流れを、結果のフレームワークは、アプリケーションフレームワークです。一般的なフレームワークと比較すると、アプリケーションフレームワークは、ビジネス目標の分野でより多くのドメイン知識を知っておく必要があります。
特定のアプリケーションを実装する場合、共通のフレームとフレームの組み合わせ、複数の方法によって適用することができ、良好な高速、高品質なアプリケーションの開発です。例えば、金融部門のアプリケーションは、金融枠組みが金融ビジネス・ロジックに関連する問題に対処するために、アプリケーション・フレームワークとして使用することができ、NHibernateはを使用してデータアクセスがESFramework各分散システムのアプリケーションとの間の通信を解決使用し、解決します。
次の図は、ライブラリ、およびアプリケーションフレームワークとの間の階層関係を説明しています。 もちろん、アプリケーションは任意のフレームワークを使用せず、完全であってもよいが、（例えば.NET Frameworkなど）下の最も基本的なAPIから構築するために始めたことがあります。マイクロシステムの場合、このアプローチは機能することができます。しかし、大規模なアプリケーションの複雑さのため、難易度は想像することができます。
1.3アプリケーションフレームワークで
選択したアプリケーションフレームワークは、私たちが行う必要がある場合、つまり、「血」と「肉」の使用は、その結果、骨格埋めるために拡張ポイントを提供するために、所定の位置に特定のアプリケーションロジックフレームワークを追加している「とは、生物の。」
フレーム以来、繰り返し使用した後、通常は、実際にテストしたので、私たちは可能より安定したシステムを実現するために短い時間と少ないコードを使用することができます品質の一定の保証は、あります。もちろん、フレームワークは「銀の弾丸」ではない、それはソフトウェアの複雑さの根本的な問題を解決していませんが、私たちは一歩近づく究極の理想的な目標にそれを渡します。
もう一つ注意すべきは、フレームワークは、それはまた、制限を与え、同時にシステムのサポートを持っているために私たちをことができます。通常、我々は特定のフレームワークの使用を決定する場合ので、私たちは「箱」の枠組みの中で制限する必要がありますし、私たちのアプリケーションを構築します。時間のほとんどは、これは問題ではありませんが、フレームの制限のと真剣に我々のシステムの目標を達成するための時間に影響を与えているのであれば、我々は、彼らがこのフレームワーク、またはその他の変更フレームワークのと同じタイプを放棄すべきかどうかを検討する必要があります。
1.4デザインフレームワーク
フレームワークは、私たちはより高速なアプリケーション開発をスピードアップすることができ、高品質、低コスト、これらの利点は自明です。しかし、口で言う無数の変化、ますます複雑なソフトウェア要件、設計に直面し、再利用可能な容易にするために非常に柔軟なフレームワークを実装！
アプリケーション由来のフレームワークが、アプリケーションよりも高いです。
フレームワークは、多くの場合、このようにして製造されています。我々は、アプリケーションの特定の種類を開発するために多くの経験を持って、我々は、CCPのこのタイプは、多重化を準備するために、高レベルにそれを精緻化するかをまとめたもの。この「ハイレベル」のプロトタイプフレームは何ですか。私たちは経験を蓄積し続けると、フレームワークが改善し、開発していきます。
フレームワークは、実際の製品ではなく、研究室のうち、理論的な研究です。だから、常に特定のアプリケーション、抽出枠を精製、目標と同じタイプのアプリケーションのための一般的なソリューションを提供するために、特定のアプリケーションから起動するフレームワークを設計するための最良の方法！このフレームワークは、アプリケーションで使用され、継続的プロセスの使用を修正し、改善されています。
ソフトウェアアーキテクチャ設計のすべての要素と同様に、注意すべきことの一つは、（ビットこの分野における技術のような）トレードオフであり、設計のフレームワークは、前述したように、例外ではない骨格のアプリケーションのためのフレームワークを提供するだけでなく、へフレームの我々のアプリケーションの描写は、我々は、この限られた世界で再生することができます。だから、良いフレームワークは、我々のアプリケーションのための強力なサポートを提供しながら、フレームワークに非常に適切なトレードオフの決定を使用して設計されていますが、私たちのアプリケーション上の制限が少ないためにする必要があります。バランス、決して単純な問題ではなく、多くの経験は、私たちの参考のためにすることができ、フレームワークの設計にあります。
1.4.1設計経験の枠組み、原則
（1）あまりにも多くの仮定を行うためのフレームワークを使用しないでください！
現象は非常に具体的、先制のフレームワークであることを前提に、あまりにも多くを行うためのアプリケーションのためのフレームワークは、アプリケーションはもともと自分の上にサッカーをやるつもりでした。これは典型的な報われない習慣です。フレームワーク横取り、シンプルを開発する特定のアプリケーションを作るかもしれませんが、より多くのこのの足かせと負担を増加させるためのフレームワークを適用することになるでしょうする必要はありません。
（2）インタフェースを使用して、すべての重要な実装の枠組みを交換することができるように提供されることを確実にします。
結局のところ、いないアプリケーションフレームワーク、そのフレームワークが、それが現在の状況が提供するフレームワークに基づい部分に置き換えるために、アプリケーションを非常に重要な可能され、すべてのコンポーネントが重要な実装を交換することが可能であることを確認するために、すべてのアプリケーションの特定の状況を考慮することはできませんコンポーネントのデフォルトの実装。フレームコンポーネントと再利用性を高めるために、フレームの個々の構成要素間の接続を定義するインターフェイスを使用。
（3）フレームワークは、簡潔な一貫性、および標的濃度であるべきです。
フレームワークは、フレームワークの各成分の存在を保証するために、ターゲットフレームワークに問題ではありませんでしたそれらのものが含まれていない、シンプルであるべき目標フレームの達成をサポートすることです。あまりにも多くの不必要な要素（クラス、インタフェース、列挙型など）、フレームワークは、あなたがより明確にフレームを作ることができ、ライブラリへのフレームワーク要素のコアの目的のためにこれらの重要度の低いを転送しようとし、理解することは困難になるだろうが、よりターゲットを絞っ濃縮しました。
（4）一般的なフレームワークを提供するが、骨格構造に固定されていない、骨格は、アセンブリを行うことも可能です。
それがビジネスプロセスのためのフレームワークのいくつかの種類である場合、例えば、そのフレームワークは、ビジネスプロセスのセットを提供しなければならないだけでなく、各ステップを再組み立てすることができるように、変更することはできないが、プロセスフローは「ワンステップ」技術でなければならないので結果として、アプリケーションは、実際の状況に応じてデフォルトフレーム処理フローを変更することができるであろう。この能力は、カスタマイズすることができるフレームワークを大幅に再利用の枠組みを改善することができます。
（5）連続フレームを再構成。
品質のフレームワークの設計と実装の秘密は何ですか？唯一の答えは、復興、絶えず改造。再構成の実装コードの枠組み、及び再構成されたフレームの偶数設計。駆動力の再構築は、このような準備を明確に理解した上で解決すべき問題の性質として、いくつかの観点から、茎、我々は、そのような時間のフレームワークを使用しての枠組みの中で明確性の欠如など、使いにくい特定のコンポーネントの責任が明確でないことを、階層構造を発見しました。
良いフレームワークとしてみなされるべき方法1.4.2？
シンプル：フレームワークの主な特徴の一つは、良好です。優れたフレームワークは、このシンプルフレームワークは常に洗練と改善を続け、スピンする必要が達成することは容易ではありませんので、このシンプルさは、取得することは容易ではありません。単純な理由はそれが本当に解決すべき問題の本質を捉えていることです。良好なフレームは、一般的に次の特性があります。
（1）透明な、簡潔で一貫した。
階層的なフレームワークが明確で明るい「クリア」フレームワークの構造を指すは明らかである、様々なクラスおよびコンポーネントの責任フレームワークは、明確かつ明白です。
「シンプル」の設計原理に反映されている非常に集中しているない取るに足らない過剰フレームワーク、目的及び様々なクラスおよびコンポーネントの責任を行う要素を指す「高凝集および低結合」。
「全会一致」は、通常、このようなメリットをもたらし、フレームの一部の後枠に精通しているユーザーは、フレームワークの他の部分は非常に理解しやすいだろう。「マッチング」は、一般的に命名規則に反映され、アセンブリが部品等の使用方法と一致名前の意味、同じです。
（2）使いやすいです
フレームワークを使用するためだけに簡単にさらに移動します。
これは、使いやすさのため、ユーザーはこのフレームワークを試す可能なフレームワークであるため、裁判の満足度の後まで、このフレームワークの決定を採用することが可能です。フレームワークの機能をさらに強力であれば、使用することは困難であれば、ユーザーが簡単にこのフレームワークをしようとするアイデアを持っていないフレームに可能性がありますので。
誰もが、このフレームワークを使用しない場合は活力がフレームワークに由来するフレームワークは、動力源のない開発及び改善できなくなる、改善及び発展を続けています。ユーザーフレンドリーなインターフェイスが不可欠優れたアプリケーションの重要な部分であるとして、それを使用して簡単には良いフレームワークの重要な特性です。
（3）非常にスケーラブルで柔軟な
高度にスケーラブル介してアプリケーションの無数の変化に対処するためのフレームワーク。
単一のフレームワークは、すべてのアプリケーションのニーズを先取りすることはできません、ユニバーサルフレームワークが存在しません。ユニバーサルフレームワークのアイデアを設計し、実装するための試みは不合理です。フレームワークは、フレームワークは、十分な拡張ポイントを使用する権利を留保してこれを行うことができ、「現状維持」する能力を持っている必要があります。
現在のフレームワークは同じカスタムアプリケーションのために設計されているようなフレームワークで具現柔軟なフレームワークは、アプリケーションに応じて組み立てられ、異なって構成することができます。
（4）軽量
「軽量」、人気のポイントは、あなただけはしないサービスのために支払うことなく、彼らが使用するサービスの支払いにあると述べました。非常に明白な特徴があるヘビー級のフレームワークを使用すると、サービスパッケージの完全なセットを必要とする場合、それは、フレームはあなたを満たすために非常に良いことができても問題ありませんということです。しかし、あなたは唯一の小型パッケージでこれを必要とする場合ブロックデザートは、私は申し訳ありませんが、フレームワークは、まだあなたは、パッケージ全体のコストを支払わなければならない、あなたに完全なパッケージを課します。
優れたフレームワークでは、ユーザが自由に「アラカルト」の枠組みは、彼らのニーズを満たすために組み立てができ、「需要が撮影した」利用者の原則をサポートする必要があります。
（5）弱侵襲
できるだけ多くのことができるアプリケーションフレームワークを使用して、「弱侵襲」は、いわゆる一般的ないくつかの特別な技術を使用していたフレームワークを適用することなく、アプリケーションのロジックを記述するための方法。
これは、我々は簡単な説明するための例を与えることができ、理解することは少し難しいかもしれません。AOP（アスペクト指向プログラミング）及び機構を実現する.NETの二つの主な方法は、動的プロキシエージェントを使用することです。AOPフレームワークプロキシの実装は通常、これらのクラスは、機能を傍受するためにAOPを使用する必要がある必要が使用されなければならないと使用AOPフレームワーク動的プロキシの実装では何もそれほど邪魔に要求されていない、我々はまだアプリケーションのロジックを記述するための最も一般的な方法することができます。ContexBoundObjectから継承されましたクラス、そのようなフレームワークは、動的にターゲットオブジェクトを生成するために応じて配置されたランタイムAOP遮断プロキシオブジェクトで実装されるであろう。だから我々は弱い侵襲的で、達成するためにAOPフレームワークを実現するために、動的エージェントプロキシ方法についてはAOPフレームワークを使用する場合と比較することを言うことができます。
アプリケーションロジッククラスはさらに、プログラムに多重非常に便利なアプリケーションロジックである通常のクラスであるので、別のプログラムが完全に異なるフレームを採用してもよいしつつ弱いフレームは、侵襲的なアプリケーションロジックの干渉が少ないことを意味します。
要約：アセンブリは、イベントの入出力処理機能を、開発および設計をスピードアップ、コードの再利用性を高めることです。関係では、パッケージツール型のメソッドを継承し、独自のデザイン・ロジックによって機能の実現のために、この機能のために独自の設計を実装するためのプログラム、プログラム開発者に呼ばれています。
最大の違いは、フレームワークの実現のためのフレームワークは、完全な機能とデザイン、フレームワーク自体の完全な実現は、この関数のロジックをカプセル化しているだけではプログラム開発でこの機能を実装するためのフレームワークを適用する必要があります。行うためのプログラムがそれを直接適用され、唯一のアプリケーションコードやカスタム置換機能のためのいくつかのオープンインタフェースを実現することができます。
ちょうどプログラムに位置するフレームの内側を埋めるために、フレームが棚になるように、プログラムは、設計フレームワークの開発に協力する必要があるように、プログラムの中で呼び出される必要があるものの完全に機能する一部の実現のためのフレームワークで開発されたフレームワークを使用してで。アセンブリは、プログラムの下にあり、それは多くの場合だけで、問題に対処する結果を返す、と呼ばれるようになります。
フレームワークプログラムが設定されているが、比較的一般的なアセンブリは、フレームワークは、アプリケーションパッケージの最上位で、より高度です。
フレーム部材は、アプリケーションのアーキテクチャを定義する再利用可能に設計することで全体のデザインを示し、抽象クラス及び例のセットとの間の連携を示し、協働する部材、責任の割り当て、および制御フロー間の依存関係します多重化されたコンテキスト（文脈）の関係部材を提供する方法。ライブラリやフレームワークを再利用するためのフレーム設計の再利用のソリューションを解決するために、主に、再利用を解決するために生まれ、主に決済手続きコードにライブラリを再利用しています。
オリジナルます。http：//blog.sina.com.cn/s/blog_732ae613010155gj.html