Spring MVCのインタビューの質問

Spring MVC implements a clear separation of concerns that allows us to develop and unit test our applications easily。

次のような概念：

互いに完全に独立しており、1つのことだけを担当します。

したがって、MVC gives us quite big flexibility。 これは（提供された実装クラスを備えた）インターフェースに基づいており、カスタムインターフェースを使用してフレームワークのすべての部分を構成できます。

Another important thing is that we aren’t tied to a specific view technology (for example, JSP), but we have the option to choose from the ones we like the most。

また、we don’t use Spring MVC only in web applications development but in the creation of RESTful web services as well。

The @Autowired annotation can be used with fields or methods for injecting a bean by type。 このアノテーションにより、SpringはコラボレーションBeanを解決してBeanに注入できます。

詳細については、@Autowired in Springに関するチュートリアルを参照してください。

@ModelAttributeアノテーションは、SpringMVCで最も重要なアノテーションの1つです。 It binds a method parameter or a method return value to a named model attribute and then exposes it to a web view。

メソッドレベルで使用する場合、そのメソッドの目的が1つ以上のモデル属性を追加することであることを示しています。

一方、メソッドの引数として使用する場合、モデルから引数を取得する必要があることを示します。 存在しない場合は、最初にインスタンス化してからモデルに追加する必要があります。 モデルに表示されたら、名前が一致するすべてのリクエストパラメータから引数フィールドに入力する必要があります。

このアノテーションの詳細については、article related to the @ModelAttribute annotationをご覧ください。

@Controllerアノテーションと@RestControllerアノテーションの主な違いは、the @ResponseBody annotation is automatically included in the @RestControllerです。 これは、ハンドラーメソッドに@ResponseBodyで注釈を付ける必要がないことを意味します。 応答タイプをHTTP応答本文に直接書き込む場合は、@Controllerクラスでこれを行う必要があります。

We can use the @PathVariable annotation as a handler method parameter in order to extract the value of a URI template variable。

たとえば、www.mysite.com/user/123からIDでユーザーをフェッチする場合は、コントローラーのメソッドを/user/{id}としてマップする必要があります。

The @PathVariable has only one element named value. It’s optional and we use it to define the URI template variable name。 value要素を省略する場合、URIテンプレート変数名はメソッドパラメーター名と一致する必要があります。

また、次々に宣言することにより、複数の@PathVariableアノテーションを付けることもできます。

または、それらをすべてMap<String, String>またはMultiValueMap<String, String>に入れます。

Spring MVC supports JSR-303 specifications by default. We need to add JSR-303 and its implementation dependencies to our Spring MVC application。 たとえば、Hibernate Validatorは自由に使用できるJSR-303実装の1つです。

JSR-303は、JavaEEおよびJavaSEの一部であるBean検証用のJava APIの仕様であり、@NotNull、@Min、％（（t1）sなどのアノテーションを使用してBeanのプロパティが特定の基準を満たすことを保証します。 t2）s。 検証の詳細については、Java Bean Validation Basicsの記事をご覧ください。

Spring offers the @Validator annotation and the BindingResult class。 Validatorの実装では、無効なデータがある場合、コントローラー要求ハンドラーメソッドでエラーが発生します。 次に、BindingResultクラスを使用してこれらのエラーを取得できます。

既存の実装を使用する以外に、独自の実装を作成できます。 そのためには、まずJSR-303仕様に準拠する注釈を作成します。 次に、Validatorクラスを実装します。 もう1つの方法は、SpringのValidatorインターフェースを実装し、Controllerクラスの@InitBinderアノテーションを介してバリデーターとして設定することです。

独自の検証を実装して使用する方法を確認するには、Custom Validation in Spring MVCに関するチュートリアルをご覧ください。

The @RequestBody annotation, used as a handler method parameter, binds the HTTP Request body to a transfer or a domain object。 Springは、Httpメッセージコンバーターを使用して、Javaオブジェクトへの着信HTTP要求を自動的に逆シリアル化します。

When we use the @ResponseBody annotation on a handler method in the Spring MVC controller, it indicates that we’ll write the return type of the method directly to the HTTP response body。 Modelには入れず、Springはビュー名として解釈しません。

これらのアノテーションの詳細については、@RequestBody and @ResponseBodyの記事をご覧ください。

The Model interface defines a holder for model attributes。 The ModelMap has a similar purpose, with the ability to pass a collection of values。 次に、それらの値をMap内にあるかのように扱います。 Model（ModelMap）では、データしか保存できないことに注意してください。 データを入力し、ビュー名を返します。

一方、with the ModelAndView, we return the object itself。 返されるオブジェクトには、データやビュー名など、必要なすべての情報を設定します。

詳細については、Model, ModelMap, and ModelViewの記事をご覧ください。

The @SessionAttributes annotation is used for storing the model attribute in the user’s session.Session Attributes in Spring MVCに関する記事に示されているように、コントローラークラスレベルで使用します。

前の例では、@ModelAttributeと@SessionAttributesの名前属性が同じである場合、モデル属性 ‘todos‘がセッションに追加されます。

If we want to retrieve the existing attribute from a session that is managed globally, we’ll use @SessionAttribute annotation as a method parameter：

The @EnableWebMvc annotation’s purpose is to enable Spring MVC via Java configuration。 XML構成の<mvc: annotation-driven>と同等です。 このアノテーションは、WebMvcConfigurationSupportからSpringMVC構成をインポートします。 これにより、@RequestMappingを使用して着信要求をハンドラーメソッドにマップする@Controllerアノテーション付きクラスのサポートが有効になります。

これと同様のアノテーションの詳細については、Guide to the Spring @Enable Annotationsをご覧ください。

The ViewResolver enables an application to render models in the browser –実装を特定のビューテクノロジに結び付けない–by mapping view names to actual views。

ViewResolverの詳細については、Guide to the ViewResolver in Spring MVCをご覧ください。

BindingResult is an interface from org.springframework.validation package that represents binding results. We can use it to detect and report errors in the submitted form。 呼び出すのは簡単です。検証するフォームオブジェクトの直後にパラメータとして配置する必要があります。 オプションのModelパラメータは、custom validator tutorialに見られるように、BindingResultの後に来る必要があります。

When Spring sees the @Valid annotation, it’ll first try to find the validator for the object being validated.次に、検証アノテーションを取得し、バリデーターを呼び出します。 最後に、見つかったエラーをBindingResultに配置し、後者をビューモデルに追加します。

The form backing object or a Command Object is just a POJO that collects data from the form we’re submitting。

ロジックは含まれておらず、データのみが含まれていることに注意してください。

Spring MVCのフォームでフォームバッキングオブジェクトを使用する方法については、Forms in Spring MVCに関する記事をご覧ください。

It is used simultaneously with the @Autowired annotation to avoid confusion when multiple instances of a bean type are present。

例を見てみましょう。 XML構成で2つの同様のBeanを宣言しました。

Beanをワイヤリングしようとすると、org.springframework.beans.factory.NoSuchBeanDefinitionException.が返されます。これを修正するには、@Qualifierを使用して、どのBeanをワイヤリングする必要があるかをSpringに通知する必要があります。

@Requiredアノテーションはsetterメソッドで使用され、このアノテーションを持つBeanプロパティは構成時に入力する必要があることを示します。 それ以外の場合、SpringコンテナはBeanInitializationException例外をスローします。

また、@Requiredは@Autowiredとは異なります。セッターに限定されているのに対し、@Autowiredはそうではありません。 @Autowiredは、コンストラクターとフィールドとの接続にも使用できますが、@Requiredは、プロパティが設定されているかどうかのみをチェックします。

例を見てみましょう：

ここで、Person Beanのnameを次のようにXML構成で設定する必要があります。

@Required doesn’t work with Java based @Configuration classes by defaultに注意してください。 すべてのプロパティが設定されていることを確認する必要がある場合は、@Beanアノテーション付きメソッドでBeanを作成するときに行うことができます。

In the Front Controller pattern, all requests will first go to the front controller instead of the servlet。 It’ll make sure that the responses are ready and will send them back to the browser. This way we have one place where we control everything that comes from the outside world.

フロントコントローラーは、最初にリクエストを処理するサーブレットを識別します。 次に、サーブレットからデータを取得すると、レンダリングするビューが決定され、最後に、レンダリングされたビューが応答として返送されます。

実装の詳細を確認するには、Guide to the Front Controller Pattern in Javaを確認してください。

モデル1とモデル2は、Java Webアプリケーションの設計に関して頻繁に使用される2つの設計モデルを表しています。

In Model 1, a request comes to a servlet or JSP where it gets handled。 サーブレットまたはJSPは、リクエストを処理し、ビジネスロジックを処理し、データを取得および検証し、レスポンスを生成します。

このアーキテクチャは実装が簡単なので、通常は小さくてシンプルなアプリケーションで使用します。

一方、大規模なWebアプリケーションには便利ではありません。 多くの場合、ビジネスロジックとプレゼンテーションロジックが結合されているJSPで機能が複製されます。

モデル2は、Model View Controllerデザインパターンに基づいており、コンテンツを操作するロジックからビューを分離します。

Furthermore, we can distinguish three modules in the MVC pattern: the model, the view, and the controller。 モデルは、アプリケーションの動的データ構造を表します。 データとビジネスロジックの操作を担当します。 ビューはデータの表示を担当し、コントローラーは前の2つの間のインターフェースとして機能します。

モデル2では、要求がコントローラーに渡され、コントローラーは、表示されるべき正しいコンテンツを取得するために必要なロジックを処理します。 次にコントローラーは、通常はJavaBeanまたはPOJOとしてコンテンツをリクエストに戻します。 また、どのビューでコンテンツをレンダリングするかを決定し、最終的にリクエストをコンテンツに渡します。 次に、ビューはデータをレンダリングします。

Springの公式ドキュメントによると、@ComponentはSpringが管理するコンポーネントの一般的なステレオタイプです。 @Repository、@Service、および@Controllerは、それぞれ、永続性、サービス、およびプレゼンテーション層など、より具体的なユースケース向けの@Componentの特殊化です。

最後の3つの特定のユースケースを見てみましょう。

簡単に言えば、フロントコントローラーのデザインパターンでは、単一のコントローラーが、着信HttpRequestsをアプリケーションの他のすべてのコントローラーとハンドラーに送信する役割を果たします。

SpringのDispatcherServletはこのパターンを実装しているため、HttpRequestsを適切なハンドラーに正しく調整する責任があります。

一方、ContextLoaderListenerは、SpringのルートWebApplicationContextを起動およびシャットダウンします。 これは、ApplicationContextのライフサイクルをServletContext.のライフサイクルに結び付けます。これを使用して、さまざまなSpringコンテキストで機能する共有Beanを定義できます。

DispatcherServletの詳細については、to this tutorialを参照してください。

The MultipartResolver interface is used for uploading files。 Springフレームワークは、Commons FileUploadで使用するための1つのMultipartResolver実装と、サーブレット3.0マルチパート要求の解析で使用するための別の実装を提供します。

これらを使用して、Webアプリケーションでのファイルのアップロードをサポートできます。

Spring MVCインターセプターを使用すると、クライアントリクエストをインターセプトし、リクエストの処理前、処理後、または完了後（ビューがレンダリングされるとき）に3つの場所で処理できます。

インターセプターは、横断的な関心事に使用でき、ロギング、Springモデルでグローバルに使用されるパラメーターの変更などの反復的なハンドラーコードを回避できます。

詳細とさまざまな実装については、Introduction to Spring MVC HandlerInterceptorの記事をご覧ください。

A method annotated with @InitBinder is used to customize a request parameter, URI template, and backing/command objects。 コントローラで定義し、リクエストの制御に役立ちます。 In this method, we register and configure our custom PropertyEditors, a formatter, and validators。

注釈には ‘value‘要素があります。 設定しない場合、@InitBinderアノテーション付きメソッドが各HTTPリクエストで呼び出されます。 値を設定すると、メソッドは、名前が ‘value‘要素に対応する特定のコマンド/フォーム属性および/またはリクエストパラメータにのみ適用されます。

It’s important to remember that one of the arguments must be WebDataBinder.他の引数は、コマンド/フォームオブジェクトと対応する検証結果オブジェクトを除いて、ハンドラーメソッドがサポートする任意のタイプにすることができます。

The @ControllerAdvice annotation allows us to write global code applicable to a wide range of controllers。 コントローラーの範囲を、選択したパッケージまたは特定の注釈に結び付けることができます。

デフォルトでは、@ControllerAdvice applies to the classes annotated with @Controller (or @RestController)です。 さらに具体的にしたい場合に使用するいくつかのプロパティもあります。

If we want to restrict applicable classes to a package, we should add the name of the package to the annotation：

複数のパッケージを使用することもできますが、今回はStringの代わりに配列を使用する必要があります。

Besides restricting to the package by its name, we can do it by using one of the classes or interfaces from that package：

‘assignableTypes‘要素は@ControllerAdviceを特定のクラスに適用し、 ‘annotations‘は特定の注釈に対して適用します。

It’s noteworthy to remember that we should use it along with @ExceptionHandler。 この組み合わせにより、すべてのコントローラークラスに対して毎回実装する必要なく、グローバルでより具体的なエラー処理メカニズムを構成できます。

The @ExceptionHandler annotation allows us to define a method that will handle the exceptions。 We may use the annotation independently, but it’s a far better option to use it together with the @ControllerAdvice.したがって、グローバルエラー処理メカニズムを設定できます。 In this way, we don’t need to write the code for the exception handling within every controller。

Error Handling for REST with Springに関する記事の例を見てみましょう。