コアのDispatcherServlet拡張周りのSpring MVCフレームワークは、DispatcherServletのは、要求をインターセプトし、適切なプロセッサに割り当てられた責任があるのSpring MVC、チーフプランナー、の一般的なディレクターです。スプリングMVCアノテーション駆動フレームは、情報処理コントローラを含み、要求に応じて、ビューアップロードファイル、例外処理用の解像度、局所的、などのラベルには、フォームを結合します。
1.アーキテクチャ
Spring MVCのは、技術的な実装のフレームワークモデル2に基づいており、モデル2は、古典的なMVC（モデル、ビュー、コントロール）モデルのWebアプリケーション変異体である、この変化は、ステートレスなプロトコルHTTPに主です。モデル2とMVCオブジェクトは、単に別のプロセッサ・モデル、ビュー、コントロールの使用として、ルーズカップリング技術の層、システムの柔軟性、保守性および再利用性の異なるレベルの効果を達成します。ほとんどの場合、MVCモデル2を同一視することができます。
一緒にすべてのロジックとビジネスロジックを表示するには、モデル2を使用する前に、時々、モデル1のため、このアプリケーションモデルと呼ばれます。モデル1の主な欠点はしっかりと、差再利用性、高いメンテナンスコストを結合されています。
スプリングMVCモデル2はフレームに基づいて達成されるため、基礎となるメカニズムがMVCであるように、スプリングMVCは、図の以下の全体的なアーキテクチャによって記載されています。
リクエストを受信するだけでなく、その職務、整然とジョブとSpring MVCの努力の多くのコンポーネントを応答を返します。フレームワークを通して、作業要求の処理を完了するために様々な構成要素の調整と組織の原因であると応答を返すコア内のDispatcherServlet位置。すべての要求を受信したフロントエンドスプリングMVC Servietを介して、特に他のコンポーネントに委託処理するためのほとんどのWebフレームワークと、DispatcherServletの春MVCの前端はサーブレットです。ここでの要求の処理のSpring MVCの全体のプロセスを説明します。
（1）全体のプロセスは、HTTPリクエストを送信するクライアントで始まり、Webアプリケーション・サーバーは、この要求を受けました。（web.xmlで指定された）整合経路マップ要求のDispatcherServlet場合、WebコンテナのDispatcherServletプロセスへの要求。
（2）（URL、HTTPメソッド、要求ヘッダー、要求パラメータ、クッキー、などを含む）情報要求に応じて、この要求を受信し、プロセッサはHandlerMapping処理要求（ハンドラ）を見つけるように構成さのDispatcherServlet後。ルートコントローラとして見ることができ、ハンドラーは、ターゲットホストとして見られます。実際には、任意のオブジェクトは、要求処理することができ、春のMVCでHandlerインタフェースを定義していない、ということは注目に値します。
（3）のDispatcherServletハンドラは、現在の要求に対応する場合、カプセル化によって得られたハンドラHandlerMapping HandlerAdapterによれば、その後、均一なアダプタインターフェースハンドラを呼び出します。HandlerAdapterは、Spring MVCフレームワークレベルのインターフェイスは、定義により、HandlerAdapterが統一されたインタフェースのメソッドハンドラのさまざまな呼び出しアダプタです。
処理後（4）プロセッサの論理名とモデルビュー・データを含むのModelAndViewのDispatcherServlet、のModelAndViewを返すために、ビジネスロジックを実行します。
（5）のModelAndViewオブジェクトの論理ビュー名ツーワーク現実的なビューを完了ViewResolverによって「論理ビュー名」ではなく、真のビューオブジェクトのDispatcherServletを含有していました。
モデルデータの使用上のビュー・オブジェクトの実際のビュー、のDispatcherServletのModelAndViewビューがレンダリングされたビュー内のオブジェクトと（6）を得ます。
（7）最終応答メッセージを取得するには、クライアントは通常のHTMLページであってもよいし、そのようなメディアの異なる形態として、XMLやJSON文字列、あるいは画像やPDF文書である可能性があります。
上記の各ステップは、知識が豊富に含まれ、この章では、徐々にの各コンポーネント明らかにする「本当の色を。」しかし、今、すべての好奇心を片付けてください、私たちの最初のステップは、Spring MVCの「心」がアップビートので、web.xmlでのDispatcherServletを設定することです。
2. [設定DispatcherServIet
DispatcherServletの春のMVCは、HTTPリクエストとSpring MVCの要求処理を行った作業のさまざまなコンポーネントを座標を受信するための責任がある「魂」と「心」、です。そして、任意のサーブレット、ユーザーは、web.xmlでのDispatcherServletを設定する必要があります。
春のMVCフレームワークの仕組みを理解するために、我々は、次の3つの質問に答える必要があります。
どのように特定のHTTPリクエストをインターセプトする（1）DispatcherServletのフレームワークへとSpring MVCのフレームワーク契約に引き渡さ？
層は、Web Beanは豆ビジネス層を呼び出すことができるように（2）ビジネス層に関連付けられる方法春のWeb上にあるコンテナ（WebApplicationContext）は、Springコンテナ（ApplicationContextの）に位置していますか？
（3）スプリングMVCの様々な構成要素を初期化し、そして内のDispatcherServletにそれらをアセンブルする方法？
1）設定のDispatcherServlet、インターセプト特定のURL要求
ご存知のように、私たちは、web.xmlにサーブレットを設定し、<サーブレットmapprng>によって、その処理のURLを指定することができます。これは、従来のDispatcherServletの設定です。Spring4.0は、従って、プログラム設定モードを使用することもできる、サーブレット3.0を完全にサポートしています。サーブレット3.0ベースの新しい方法を説明し、紹介するのweb.xmlのここで最初の伝統的な方法。web.xmlに次のように次のコードのように私たちが傍受できるのDispatcherServlet Spring MVCのにしたいと終了の.htmlへのすべての要求のURLを処理すると仮定し、それは、設定することができます。
<！ - - ①ビジネス層と永続化層Spring構成ファイル、設定ファイルは、親コンテナの春で使用されている>
< 文脈のparam > < PARAM名> contextConfigLocation </ PARAM名> < PARAM値> CLASSPATH ：/applicationContext.xml </ PARAM値> </ コンテキストのparam > < 聞き手> < リスナークラス> org.springframework.web.context.ContextLoaderListener </ リスナクラス> </ リスナー>
< - ②声明！ DispatcherServletの- > < サーブレット> <サーブレット名>スマート</ サーブレット名> < サーブレットクラス> org.springframework.web.servlet.DispatcherServlet </ サーブレットクラス> < のload-on-startup > 1 </ のload-on-startup > </ サーブレット> <！ - ③名为のDispatcherServlet匹配的URL模式- > < のservlet-mapping > < サーブレット名>スマート</ サーブレット名> < のurl-pattern > .htmlの </ のurl-pattern > </ のservlet-mapping>
①において、Springコンテナ層はcontextConfigLocationパラメータ（カンマで区切られた複数のプロファイル）によってサービスプロファイルを指定します。ContextLoaderListenerは、パラメータ春contextConfigLocationプロファイル開始「ビジネス層」Springコンテナによって指定されていること、のServletContextListenerです。
②部門でのDispatcherServletは、SpringコンテナのWeb層を起動し、デフォルトで自動的に/WEB-INF/smart-servlet.xml(<servlet-Name>-servlet.xml）Spring構成ファイルをロードした、スマートと呼ばれるように構成。
③で、<サーブレットmappmg>によって.htmlのHTTPリクエスト、即ち、.htmlのサフィックスを持つすべてのHTTP要求が傍受とのDispatcherServletに処理される全てのDispatcherServletサフィックスを処理するように指定。
私たちは、それが良いデカップリングを達成するために、父と息子の関係より春のコンテナレベルの間に設定することができます知っています。ここで、「ウェブ層」Springコンテナ「ビジネス層」サブコンテナSpringコンテナ、すなわち「ウェブ層」コンテナは、「ビジネス層」コンテナ豆、および「ビジネス層」コンテナを参照することができますが、「ウェブ層を訪問することはないとして「ビーンコンテナ。
それぞれのDispatcherServletが異なる要求を処理するようにしますが、その<のservlet-mapping>の設定により、複数のweb.xmlのDispatcherServletを設定することができ、思い出すことする必要があります。
「コンフィギュレーションを超える契約」の原則に従うのDispatcherServlet、ほとんどの場合、ユーザーが追加の設定を必要としない、契約に基づいてのみ機能することができています。
あなたが本当にデフォルトのルールのDispatcherServletを調整したい場合は、DispatcherServletのは「オープンマインド」です。以下は、いくつかの共通の構成パラメータは、<INIT-PARAM>の<サーブレット>によって指定することが可能です。
（1）名前空間：のDispatcherServlet対応する名前空間のデフォルトの<servlet-name>の-servlet、パス構成Spring構成ファイル。このプロパティを明示的に指定した後、プロファイルは、パスのWEB-INF / <名前空間> .xmlファイルではなく、WEB-INF /の<servlet-name>の-servlet.xml対応します。名前空間がサンプルに設定されている場合、対応するコンフィギュレーションファイルの春のWEB-INF / sample.xmlに
（2）contextConfigLocation：プロファイルSprlng複数に対応するコンテキストは、このプロパティは方法スプリング・リソース・パスを指定するために使用することができるのDispatcherServlet場合。"クラスパス：samplel.xml、クラスパス：sample2.xml"、DispatcherServIet samplel.xml sample2.xmlクラスパスとの両方のプロファイルの初期化WebApplicationContextを使用。
（3）publishContext：ブール属性、デフォルト値のトゥーレ。DispatcherServlet WebApplicationContext発信者手段WebApplicationContextのServletContextインスタンスによって見つけることができるように、のServletContextのプロパティのリストを公開するかどうかを決定すること、のDispatcherServlet＃getServletContextAttributeName（）メソッドの名前対応する属性は、属性に基づいて値を返します。
（4）publishEvents：ブール属性。DispatcherServletは容器にServletRequestHandledEventイベントを公開するかどうか、リクエストの処理を完了した場合、デフォルト値はtrueです。コンテナは任意のイベントリスナーを持っていない場合は、パフォーマンスを向上させるために、このプロパティをfalseに設定することができます。
春のプロファイル次のコードは、明示的にウェブ層を指定します。
< サーブレット> < サーブレット名>スマート</ サーブレット名> < サーブレットクラス> org.springframework.web.servlet.DispatcherServlet </ サーブレットクラス> < INIT-PARAM > < PARAM名> contextConfigLocation </ param-名前> < PARAM値> /WEB-INF/spring/webApplicationContext.xml </ PARAM値> </ INIT-PARAM > </ サーブレット>
前述のSpring4.0 Servlet3.0のフルサポートを持っているので、3.0環境で、また、プログラムサーブレットコンテナを設定するために使用することができます。次のコードは、コードを上記と同様の効果を得ることができます。
パブリック クラス SmartApplicationInitializerが実装WebApplicationInitializer」を @Override 公共 ボイドonStartup（のServletContext容器）{ ServietRegistration.Dynamic登録 = container.addServlet（ "ディスパッチャ"、新 のDispatcherServlet（））。 registration.setLoadOnStartup（ 1 ）。 registration.addMapping（ ".htmlを" ）; } }
そして、Servlet3.0の原則の実装を見てください。Servlet3.0環境では、コンテナは、実装クラスを有することが判明し、サーブレットコンテナを設定するために呼び出されます場合は、javax.servlet.ServletContainerInitializerを実装するクラスパスクラスに見えます。春には、org.springframework.web.SpringServletContainerInitializerクラスは、このインタフェースを実装し、このクラスはorg.springframework.web.WebApplicationInitializerクラスがインタフェースを実装して検索し、完了するために、これらのクラスを実装するためにタスクを設定します。また、春には、単にそのServietのマッピングが可能に指定登録のDispatcherServletの時にそれを作る、このインタフェースを実装するのに便利なAbstractAnnotationConfigDispatcherServletlnitializer抽象クラスを提供します。上記の例では、ときに、アプリケーションの配備容器コンテナが自動的にそれを見つけ、およびサーブレットコンテキストを設定するためにそれを使用開始し3.0、に。
2）内部ロジックを探索DispatcherServIet
Spring MVCのコンポーネントがでDispatcherServIetに組み立てられるかのコンテキストで春：最後に残った問題は今ですか？initStrategiesのDispatcherServletコード（）メソッドを調べることで、すべての真実が明るみに出るだろう。
保護された ボイドinitStrategies（ApplicationContextのコンテキスト）{ initMultipartResolver（）; // ①初期アップロードファイルパーサ（マルチパート要求パーサのリテラル翻訳） initLocaleResolver（）; // ②初期局在パーサ initThemeResolver（）; // ③初期化トピックパーサ initHandlerMappings（）; // ④プロセッサ初期化マッパ initHandlerAdapters（）; // ⑤初期化処理アダプタ initHandIerExceptionResolver（）; // ⑥初期化プロセッサ例外リゾルバ initRequestToViewNameTranslator（）; // ビュー名に⑦初期化要求トランスレータ initViewResolvers（）; // ⑧ビューリゾルバの初期化 }
初期化とBean Springコンテキストが初期化された後に自動的に実行WebApplicationContext initStrategies（）メソッド。このメソッドの動作原理は次のとおりです。ビーンSpringコンテナのユーザ定義の反射、そうでない場合は、コンポーネントアセンブリの既定のインスタンスで明示的に検索し、フィッティングアセンブリ。
スプリングMVCコンポーネントは、デフォルトの実装クラスのセットを定義し、それが明示的ビーンスプリング容器アセンブリで定義されていない場合でも、と言うことである、のDispatcherServletはまた、利用可能なコンポーネントのデフォルトセットを組み立てました。春-webmvc-4.x.jarパッケージORG / springframework /ウェブはロープロファイルDispatcherServlet.properties /サーブレットクラスパスを持っているでは、ファイルが使用されるデフォルトのコンポーネントのDispatcherServletを指定しました。
##ロケールリゾルバ
org.springframework.web.servlet.LocaleResolver = org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver
##テーマリゾルバ
org.springframework.web.servlet.ThemeResolver = org.springframework.web.servlet。 theme.FixedThemeResolver
（2）##プロセッサマップ
org.springframework.web.servlet.HandlerMapping = org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping、\
org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping
＃ （3）＃プロセッサアダプタ
org.springframework.web.servlet.HandlerAdapter = org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter、\
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter、\
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter
##例外ハンドラ（3の合計）
org.springframework.web.servlet.HandlerExceptionResolver = org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver、\
org.springframework.web.servlet.mvc.annotation。 ResponseStatusExceptionResolver、\
org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver
##视图名称翻译器
org.springframework.web.servlet.RequestToViewNameTranslator = org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator
##视图解析器
組織。 springframework.web.servlet.ViewResolver = org.springframework.web.servlet.view.InternalResourceViewResolver
org.springframework.web.servlet.FlashMapManager = org.springframework.web.servlet.support.SessionFlashMapManager
有些组件最多允许存在一个实例，如 MultipartResolver、LocaleResolver 等，而另一些组件允许存在多个实例，如 HandlerMappmg、HandlerAdapter 等。同一类型的组件如果存在多个，那么它们之间的优先级顺序如何确定呢？这些组件都实现了 org.springframework.core.Ordered接口，可通过 order 属性确定优先级顺序，值越小优先级越高。
简言之，当 DispatcherServlet 初始化后，就会自动扫描上下文的 Bean，根据名称或类型匹配的机制查找自定义的组件，找不到时则使用 DispatcherServlet.properties 定义的默认组件