まず、我々は次のIOCとDIを知るようになっ:
- IOC(制御の反転)制御の反転:制御の反転は、ニーズは達成するために、逆ヘルプをコードコンテナに応じて、実装することが、元のコード内のオブジェクトを作成することです。コンテナ、およびコンテナが作成するオブジェクトとオブジェクトのニーズとの間の関係を知っているようにする必要性の説明を作成する必要があり、我々はそう。この文書では、最も具体的な症状は設定可能ですについて説明します。
- DI(依存性注入)DI:、受動代わりにクラスを見つけるために、独自のイニシアチブに依存している被験体を指す、すなわち、それは、オブジェクト・クラスに依存容器から見つけることではなく、アクティブオブジェクトは、それに依存するクラス噴射インスタンス化された容器それに。
以下の質問について考えてみよう:
- どのようにオブジェクトとオブジェクト・リレーショナル表現?XML、プロパティファイルセマンティックプロファイルで表すことができます。
- ファイルが格納されたオブジェクト間の関係を記述する?クラスパス、その上にファイルシステム、のServletContextと。
- 設定ファイルではなく、設定ファイルを解析する必要があります。異なるプロファイルは、このような標準は、カスタムの宣言型は、どのようにそれを統一して、オブジェクトの説明と同じではありませんか?これは、すべての外部記述が定義の統一記述に変換する必要があり、対象物の内部の統一された定義が必要です。
- どのように異なるプロファイルを解析するには?別のコンフィギュレーション・ファイルの構文、異なるパーサの必要性。
私たちは春がどのように行われるかを見て次。
1.BeanFactory
春の豆は、工場出荷時のパターン、豆の植物、すなわちIOCコンテナのこのシリーズを使用して作成されたオブジェクトの管理開発者の間の依存関係のための利便性と基本的なサービスの多くを提供します。多くの春IOCは選択との関係を次のコンテナを使用するための実装があります。
ListableBeanFactory、HierarchicalBeanFactoryとAutowireCapableBeanFactory:トップレベルインターフェースクラスとしてたBeanFactoryは、基本的な機能仕様IOCコンテナ、たBeanFactory 3つのサブクラスを定義します。最後のカテゴリは、彼がすべてのインタフェースを実装し、デフォルトの実装DefaultListableBeanFactoryです。
なぜこれほど多くの定義レベルは、それをインターフェイスする必要がありますか?今これらのインタフェースと各インタフェースは、主動作中スプリング内部オブジェクト転送および変換プロセスを区別するために、彼の用途を有する発見のソースの記述は、ターゲットアクセス制限のデータが作ら。例えばListableBeanFactoryインタフェースはビーンがこれらのリストで表し、HierarchicalBeanFactoryビーンは、これらが親各ビーンビーンを持っている可能性があること、継承されていることを示しています。豆AutowireCapableBeanFactory自動組立インタフェース定義ルール。これらの4つのインターフェイスは、コレクション豆、豆、豆の行動との間の関係を定義するために一緒に働きます。
私たちはこの方法でソースコードを見たBeanFactory:
public interface BeanFactory {
// 对FactoryBean的转义定义,因为如果使用bean的名字检索FactoryBean得到的对象是工厂生成的对象,
// 如果需要得到工厂本身,需要转义
String FACTORY_BEAN_PREFIX = "&";
// 根据bean的名字,获取在IOC容器中得到bean实例
Object getBean(String name) throws BeansException;
//根据bean的名字和Class类型来得到bean实例,增加了类型安全验证机制。
<T> T getBean(String name, @Nullable Class<T> requiredType) throws BeansException;
Object getBean(String name, Object... args) throws BeansException;
<T> T getBean(Class<T> requiredType) throws BeansException;
<T> T getBean(Class<T> requiredType, Object... args) throws BeansException;
// 提供对bean的检索,看看是否在IOC容器有这个名字的bean
boolean containsBean(String name);
//根据bean名字得到bean实例,并同时判断这个bean是不是单例
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;
boolean isTypeMatch(String name, @Nullable Class<?> typeToMatch) throws NoSuchBeanDefinitionException;
// 得到bean实例的Class类型
@Nullable
Class<?> getType(String name) throws NoSuchBeanDefinitionException;
// 得到bean的别名,如果根据别名检索,那么其原名也会被检索出来
String[] getAliases(String name);
}
FACTORY_BEAN_PREFIXのために、ここでは次のように説明する:非常によく似たBeanFactoryと簡単に名前から混同FactoryBeanのというクラスがあるが、FactoryBeanの豆であるたBeanFactory最初の工場は、豆の特別な種類で、この特定の豆生産意志別のBeanは、インゲンマメのために、たBeanFactory getBeanの方法により、このBeanを得ることができ、かつFactoryBeanのために、それはむしろFactoryBeanのそのものよりも、豆のgetBean FactoryBeanの生産によって得られる、あなたがFactoryBeanの自分自身を取得したい場合は、することができます接頭辞&、春には理解し、元はFactoryBeanのを必要とされます。
IOCコンテナのたBeanFactoryのみ基本的な動作は、私たちは豆をロードする方法の定義がどのように気にしない、定義されていました。
植物は、オブジェクトがIOCコンテナの具体的な実現を参照する必要が生成することである方法を知っているために、春はIOCコンテナの数の実装を提供します。例のXmlBeanFactory、ClasspathXmlApplicationContextについては、オンそう。IOCコンテナの実現に不可欠であるXmlBeanFactoryは、IOCコンテナはBeanDefinition(BeanのXML記述ファイル)を定義するXMLファイルを読み込むことができます。ApplicationContextのは、IOCのコンテナを提供することを基本的な機能に加え、シニアIOCコンテナ春の提供ですが、また次の追加のサービスをユーザーに提供します。
- 情報源、可能な国際化をサポートしています。(インターフェイスを実装MessageSource)
- リソースへのアクセス。(ResourcePatternResolverは、インターフェイスを実装します)
- アプリケーションイベントをサポートしています。(ApplicationEventPublisherインタフェースを実現)
2.BeanDefinition
私たちは、それらの相互関係のBeanオブジェクトのさまざまな定義SpringIOC容器管理は、オブジェクトは、春の豆で達成され
、次のようにその継承システムを記述するためにBeanDefinitionに:
豆解決プロセスは、非常に細かい機能が分割され、非常に複雑です。Spring構成ファイルを解決するために、主に豆解像度。
主に完全なクラスの解像度処理により、図: