Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。編集部Springフレームワークは当初から、複雑な問題に対して強力だけれども、非侵襲的なソリューションを提供することに焦点をあててきました。2.0ではXMLベースの設定を削減する方法として、カスタムのネーム空間を導入しました。Security)、Springではないプロジェクト(たとえばCXF)に定着しています。2.5では、XMLベースの設定に取って代わるものとして、包括的なアノテーション一式を導入しました。ライフサイクルメソッド、Web層の設定、ユニット/統合検査があります。2.5で導入されたアノテーションを探究する3部作の第2弾です。Web層におけるアノテーションのサポートを扱います。最後の論文では、統合と検査で利用できる追加機能を説明する予定です。Springが管理するオブジェクトの設定と依存性注入において、XMLの代わりにどのようにJavaアノテーションを使用可能か説明しました。以下に再度、例を挙げておきます。...@ControllerはClinicControllerがWeb層コンポーネントであることを示しています。@AutowiredはClinicのインスタンスに依存性の注入を要求します。この例では、両アノテーションの承認の有効化とコンポーネント・スキャニング範囲の制限に、わずかな量のXMLだけで済みます。XMLの設定が下の層に比べて冗長になりがちで、おそらくその価値も低い傾向にあるので、わずかな量のXMLで済むというのは素晴らしいニュースです。コントローラは、view名やフォームオブジェクト名、バリデータ型など多数のプロパティを保持しますが、その目的は依存性注入よりも設定です。した設定を効率的に管理する方法として、bean定義の継承や、あまり頻繁に変更しないプロパティの設定回避があります。経験から申し上げると、多数のデベロッパがそうした方法をとらないので、結果として必要以上のXMLとなってしまうのです。@Controllerと@AutowiredはWeb層の設定に非常に好ましい効果を上げられるのです。2.5アノテーションを一通り見て回ります。MVCを意味しています。実際、この論文で説明している機能の大部分が、この2つに当てはまります。1で説明したアノテーションとは対照的に、@MVCは単なる代替設定以上のものです。Controllerの以下の有名なシグネチャを考えてみましょう。MVCコントローラは、Controllerを直接実装するか、あるいはAbstractController、SimpleFormController、MultiActionController、AbstractWizardFormControllerなど利用可能なベースクラスの実装のうちの1つから拡張します。MVCのDispatcherServletは前述したすべてを「ハンドラ」として扱うことができ、SimpleControllerHandlerAdapterというアダプターの助けを借りて、こうしたハンドラを呼び出すことができるのです。@MVCはこのプログラミング・モデルを3つの特筆すべき方法で変更します。インターフェースやベースクラスの必要条件は皆無リクエスト処理メソッドの数に制限無しメソッドのシグネチャに高度の柔軟性この3点を考えると、@MVCはただの代替ではない、と言えるでしょう。MVCのコントローラ技術は進化の次段階に来ているのです。DispatcherServletはAnnotationMethodHandlerAdapterというアダプターを用いて、アノテーション付きコントローラを呼び出します。これ以降で論じるアノテーションのサポートにおいて、大部分の作業を担当するのがこのアダプターです。同アダプターは、ベースクラスコントローラの必要性を事実上なくします。Controllerに類似したコントローラから始めましょう。}ここで違っているのは、このコントローラはControllerインタフェースを拡張しないということで、さらに、@RequestMappingアノテーションを用いて、show()がURIパス「/accounts/show」にマップされたリクエスト処理メソッドであることも示しています。コントローラの型どおりのものとなっています。上記のメソッドを@MVCに完全に変換した後に@RequestMappingに戻る予定ですが、その前に、上記のリクエストマッピングURIが、以下のようなあらゆる拡張子を伴ったURIパスにも一致することに言及しておきましょう。...柔軟なリクエスト処理メソッド・シグネチャメソッド・シグネチャが柔軟である、と先ほどお約束しました。先に進めて、入力パラメータからレスポンスオブジェクトを取り除き、ModelAndViewを返す代わりに、モデルを表す入力パラメータとしてMapを追加します。そのレスポンスのレンダリング時には、Stringを返して使用するview名を示します。}Mapの入力パラメータは「暗黙の」モデルと呼ばれており、メソッドが呼び出される前に、都合よく作成されます。暗黙のモデルに対になったキー値を加えると、view(この場合show.jspページ)でのレンダリングにデータが利用可能になります。@MVCにより、HttpServletRequest/HttpServletResponse、HttpSession、Locale、InputStream、OutputStream、File[]など、多数の型が入力パラメータとして使えるようになります。どのような順番で提供されても大丈夫です。ModelAndView、Map、String、そして何よりも虚空型といった多数の戻り型も可能になります。サポートされている入力・出力パラメータ型の完全なリストについては、JavaDocの@RequestMapping(リンク)をお調べください。興味深いのは、メソッドがviewを指定しないと(たとえば戻り型が無効)、どうなるかということです。規則ではそうした場合、DispatcherServletがリクエストURIのパス情報を再利用し、先頭のスラッシュと拡張子を取り除くことになっています。戻り型を虚空に変更しましょう。}このリクエスト処理メソッドと「/accounts/show」リクエストマッピングという条件下では、DispatcherServletが「accounts/show」というデフォルトのview名にフォールバックすると予想でき、このview名が以下のような適切なviewリゾルバと組み合わされると、以前と同じ結果をもたらします。</bean>view名については規則に従うようお勧めします。規則に従っていれば、ハードコードされたview名をコントローラから排除するのに役立つからです。idに「viewNameTranslator」を割り当ててください。@RequestParamを使って構文解析パラメータを抽出@MVCのもう1つの特徴として、リクエストパラメータの抽出・解析機能があります。引き続きメソッドのリファクタリングを行い、@RequestParamアノテーションを追加しましょう。}ここでは@RequestParamアノテーションの助けにより「number」という名称のStringパラメータが抽出され、入力パラメータとして渡されます。optionalパラメータもサポートします。型変換については、すべての基本的なJava型がサポートされており、カスタムのPropertyEditorsを使って拡張可能です。以下に、requiredパラメータ、optionalパラメータの例をもう少し挙げておきます。amount最後の例で明示的なパラメータ名を提供していないことにご注意ください。すると「amount」というパラメータが抽出されますが、それはコードをデバッグシンボルを使ってコンパイルした場合に限ります。コードのコンパイルにデバッグシンボルを使用しなかった場合はIllegalStateExceptionがスローされることになりますが、その理由は、リクエストからパラメータを抽出するには情報が不十分だからです。このため、パラメータ名の明示的な指定が望ましいのです。@RequestMappingの続き選択を狭めるという効果をもたらすために、クラスレベルに置いた@RequestMappingとメソッドレベルの@RequestMappingアノテーションを併用するのは、道理にかなっています。params="type=checking")@RequestMappingクラスレベルのマッピングと併用した最初のメソッドレベルのリクエストマッピングは、「/accounts/delete」に一致しますが、この場合のHTTPメソッドはPOSTです。2番目の例では、「type」という名称のリクエストパラメータに要件を追加しますが、そのリクエストの値は「checking」になっています。3番目のメソッドではまったくパスを指定していません。このメソッドは全HTTPメソッドに一致し、必要に応じてそのメソッド名が使われます。次のようなメソッド名解決に依存するよう、メソッドを変更しましょう。...このメソッドは、「/accounts/*」のクラスレベル@RequestMappingと「show」というメソッド名に基づき、「/accounts/show」へのリクエストに一致します。Mappingの削除Web層のアノテーションに対してしばしば耳にする反対意見に、URIパスがソースコードに埋め込まれてしまうという事実があります。これについては、コントローラクラスには一致するURIパスというXML設定の戦略を用い、メソッドレベルのマッピングにのみ@RequestMappingアノテーションを使用することで、容易に解決できます。ControllerClassNameHandlerMappingを設定してみますが、ControllerClassNameHandlerMappingはコントローラのクラス名に依存する規則を使って、コントローラへのURIパスをマッピングします。「/accounts/*」へのリクエストはAccountsControllerと一致します。@RequestMappingアノテーションとの組合せでうまく機能し、上記のマッピングにメソッド名を追加することでマッピングが完了します。このメソッドではview名が返ってこないため、今度はクラス名、メソッド名、URIパス、view名を一致させる規則を使います。@Controllerを完全に@MVCに変換すると、以下のようになります。...補助となるXMLは次のようになります。</bean>ご覧のとおり、XMLは最小限で、埋め込みのURIパスや明示的なview名もなく、リクエスト処理メソッドは1行の構成で、メソッドシグネチャは必要とするものと正確に一致しており、追加のリクエスト処理メソッドも容易に付け加えられます。少なくとも直接このコントローラに帰因するベースクラスやXMLは皆無です。このプログラミングモデルの効果が、次第に分かってきたのではないかと思います。典型的なフォーム処理のシナリオには、編集するオブジェクトの検索、保持されているデータを編集モードで提示、ユーザによる提出、そして最後に変更の認証と保存が伴います。MVCには備わっています。@ModelAttribute、@InitBinder、@SessionAttributesアノテーションのおかげで、ベースクラス・コントローラが不要になったこと以外、@MVCには何の変化もありません。@ModelAttributeアノテーション以下のリクエスト処理メソッドのシグネチャをご覧ください。}上記は、リクエスト処理メソッドのシグネチャとして完全に有効です。GETを処理しています。MVCのフォームタグで使用するAccountを返します。POSTを処理します。MVCのデータバインディング・メカニズムを使って、リクエストパラメータから自動投入されるAccountを受け入れます。非常に単純なプログラミングモデルです。Accountオブジェクトには編集されるデータが保持されています。MVCの専門用語では、Accountはフォームモデルのオブジェクトとなっています。このオブジェクトは何らかの名称の下、フォームタグ(ならびにデータバインディング・メカニズム)で利用可能になっていなければなりません。以下はJSPページからの抜粋ですが、「Account」という名称のフォームモデル・オブジェクトに触れています。</form>「account」という名称をどこにも指定していませんが、それでもこのJSPスニペットは、前述のメソッドシグネチャとうまく機能するでしょう。いうと、@MVCでは返されたオブジェクト型の名称を使ってデフォルト名を選択するからです。そのため、型がAccountのオブジェクトは、デフォルトで「account」という名称のフォームモデル・オブジェクトとなるのです。デフォルトが適当でない場合は、次のように@ModelAttributeを使って名称を変更できます。ModelAttributeをメソッドレベルに置くと、少々違った効果をもたらします。}ここのsetupModelAttribute()はリクエスト処理メソッドではありません。それどころか、他のいかなるリクエスト処理メソッドの呼び出しよりも前に、フォームモデル・オブジェクトを準備するために使われるメソッドになっています。ご存知の方々からご覧になると、SimpleFormControllerのformBackingObject()メソッドに酷似しているのではないでしょうか。@ModelAttributeをメソッド上に置くと、フォーム処理シナリオで役立ちますが、最初のGET中にまず1度、フォームモデル・オブジェクトの検索が行われ、その後、ユーザの変更に伴ってデータバインディングを既存のAccountオブジェクトとオーバーレイさせたいときに発生するPOSTの際に2度目の検索が実行されます。オブジェクトの2度検索に代わる手段は、この2度のリクエスト間にオブジェクトをHTTPセッションに格納しておくことでしょう。これについては、次に検討します。SessionAttributesを使って属性を格納@SessionAttributesアノテーションは、リクエスト間のセッションに保持しておく、フォームモデル・オブジェクトの名称もしくは型の指定に使用可能です。以下に例を2つ挙げます。セッションに格納します。変更が持続する場合は、セッションから属性を取り除くべきでしょう。SessionStatusインスタンスの助けを借りて属性を削除できますが、SessionStatusインスタンスはonSubmitメソッドのメソッドシグネチャに追加されると、@MVCによって渡されます。}DataBinderのカスタマイズ時々、データバインディングにカスタマイズが必要になります。必要フィールドを指定したり、日付や通貨金額など向けにカスタムのPropertyEditorsを登録したりする必要があるかもしれません。@MVCを使えば、簡単にできます。DataBinderインスタンスにアクセスできます。各コントローラに必要なカスタマイズが可能になります。データバインディングの結果と認証データバインディングは、型変換の失敗やフィールドの欠落といったエラーをもたらす可能性があります。エラーが発生してしまったら、編集フォームに戻り、ユーザが訂正できるようにしたいものです。そのためには、フォームモデル・オブジェクトのすぐ後で、メソッドシグネチャにBindingResultオブジェクトを追加します。}エラー発生時には、BindingResultから、モデルに属性を追加した時のviewに戻るので、フィールド特有のエラーに戻ってユーザに表示します。view名を明示的に指定していないことにご留意ください。その代わりに、受け取るURIのパス情報に一致するデフォルトのview名をDispatcherServletが返せるようにしています。認証に必要なのは追加の1行のみで、ValidatorオブジェクトにBindingResultを渡すために、この1行でValidatorオブジェクトを呼び出します。これにより、バインディングエラーと認証エラーを1箇所に蓄積できます。2.5のWeb層向けアノテーション、通称@MVCの一通りの紹介は終わりです。まとめWeb層におけるアノテーションは非常に有益であることが分かっています。MVCのコントローラ技術にフルアクセスすることにより、的確かつ柔軟、そして簡潔なプログラミングモデルが可能になります。ソースコードへのURIパスの埋め込みや、view名の明示的な定義を回避するためには、コントローラへリクエストを委譲するハンドラ・マッピング戦略を中央集中化するだけでなく、「設定に勝る規約」の特色を利用することを大いにお勧めします。MVCの非常に重要な機能拡張は特筆に値します。JavaScriptライブラリ、より高度な編集シナリオをサポートする、ステートおよびナビゲーションの先進管理といった機能が追加されています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。