ASP.NETCoreOptionsPattern.pptx

Editor's Notes

• #2: ASP.NETの設定値の分離の仕方は以前から変わりません。JSONファイルに設定値を定義し、アプリケーションのホストでサービスを登録することで各メソッドが利用できるという仕組みです。ASP.NET MVCの場合はCreateBuilderで作成したホストに設定値のサービスを登録しておけば、コントローラーのコンストラクタで受け取ったサービスをコントローラーのスコープでグローバル定義された変数に格納することで、POSTやGETリクエストでの処理でその変数を利用することができます。 その際に、オプションズ・パターンを使った設定値の分離を行っておくと、保守性の良いカプセル化を行うことができます。設定値をメソッドごとやコントローラーごとにカプセル化できます。また、ログやIPホワイトリストといった「システム」と「業務」の情報のレベルでカプセル化することもできます。 さらに、関心ごとの分離も可能です。本セッションで言うところの「関心ごと」というのは、同じことを指しているがそれを使うシーンによって呼び方が異なるとも換言できます。ドメインドリブンデザインで表現すると、いくつかの同じ属性を持つそれぞれのバウンダリーコンテキストで扱う設定値が異なるといえます。最も簡単な例では、売上と支払です。ある商品を購入した際に、会員アプリで「お支払額」と表示されるのは、販売管理システムでは「売上」と表示されます。商品というオブジェクトの「価格」が会員アプリの購入履歴では「お支払額」と表示され、販売管理システムの集計表では「売上」と表示されます。関心ごとで分離する場合、販売管理システムの「売上」に付随する情報である原価や販売数、商品の色やサイズを関心ごととしてまとめられます。会員アプリの「お支払額」には、付随する情報として決済方法やポイント、履歴などを関心ごととしてまとめておくと管理しやすいと思います。 本セッションでは、オプションズパターンの特長を表現するため、グローバリゼーションの実装例を使って「同じ属性を持ちながら別々の設定値を読込むアプリケーションの継続的インテグレーション」を解説していきます。
• #3: 実案件の製品環境でグローバリゼーションを行う場合は、Microsoft Docsを参照してください。こちらのページではサービスサイドでレンダリングするページで「IHtmlLocalizer」を使ったresxファイル・リソースの呼び出しを行える実装方法を紹介しています。そのためコントローラーでページレンダリングのためのローカライズ文字列をViewDataやViewBagに入れる必要がなく、ページレンダリングのロジックがViewとControllerに分散しません。どちらがいいということではなく、継続的インテグレーションの視点で設定値をresxファイルで管理したくないとかresxファイルで管理するスキームがすでに完成している等、プロジェクトによってさまざまなケースがあるので適材適所で使い分けてください。
• #4: 自己紹介を読む
• #5: 本日のアジェンダを読む
• #7: 設定値の読込の流れは今までと変わりません。JSONファイルからbuilderにサービスを登録する際にJSONファイルの構造と同じ構造のクラスを使った読み込みを行います。 【クリック】たとえば、JapaneseとEnglishに同じ構造で日本語と英語のアクション名やページタイトルを設定しています。 【クリック】サービス登録で使うJSONファイルと同じ構造のクラスを用意します 【クリック】この例のApplicationContextクラスを奇妙に思う人は正解です。オプションズパターンのひとつの特長ですから後で解説します。これをホストにサービスとして登録します。【クリック】 【クリック】
• #8: サービスとして登録された設定値はコンストラクタで受け取れますので、クラスのグローバルレベルの変数に格納しておきます。 【クリック】そうすることでメソッドで画面のような感じで利用することができます。 【クリック】ViewDataを使っているのは、オプションズパターンの分離の際に、オブジェクトを階層化する必要があったからです。単なるカプセル化としてオプションズパターンを使う場合は、グルーピングされた階層の無い並列なキーと値の組合せのセットになりますので、ViewBagで十分なケースもあります。 【クリック】
• #9: 先ほど、ApplicationContextクラスを奇妙に思ったのはこの部分のはずです。ConfigurationサービスのEnglish定数をApplicationContextクラスにバインドするのですが、ここをJapaneseに変更することができます。 【クリック】そのため、ここはサービス登録時のように文字列リテラルを直接指定することもできます。もちろんお勧めしません。つまり、オプションズパターンでは、定数で定義された部分以外のこの部分について、定数を使ってセクションごとに特定のクラスにバインドすることができます。 そして、そのクラスが同じ属性を持つオブジェクトを表現する場合は、利用時に定数で指定しますので「JSONのセクションの定義」、「JSON定義の定数化」「その定数を使ったサービスへのセクション読込」、「サービスのセクションを指定した利用時のバインド指定」に一貫性を保持したコーディングができるようになっています。
• #10: 設定値を受け取るインスタンスの型について詳細の解説になります。 【クリック】オプションズパターンのひとつの特長ですが、こんな感じのクラスや構造体が生成されるようなイメージをしてください。実際は、中に入っているデータが英語か日本語かが重要なので、右下の図のC#10.0のレコード構造型をイメージしてもらった方がいいかもしれません。 【クリック】定数フィールドは無視され読み書き可能なプロパティで構成されたインスタンスを生成します。ApplicationContextというクラスをコードで生成した時のインスタンスは、定数で指定した名前のクラスや構造体のようにふるまいます。 【クリック】そのため定数の分だけインスタンスが生成されます。インスタンス化の際は、既定のコンストラクタである非抽象型のパラメーター無しのパブリックコンストラクタ―が使用され、そのインスタンスに定数で指定した名前に対応するJSONファイルのセクションがデシリアライズされます。これはデシリアライズの際の.NETの標準的な動作なので、gRPCのProtocol Buffersフォーマットのデータをデシリアライズする際やJSON Serializerのデシリアライズなどでも同じように非抽象型のパラメーター無しのパブリックコンストラクタ―が使用されます。 ここまでがオプションズパターンのカプセル化の話になります。ここでは英語と日本語をカプセル化しました。【クリック】
• #11: 設置値をソースコードから分離する場合、それらが「グルーピングされた階層の無い並列なキーと値の組合せのセット」で十分なのか、「階層化されている必要がある」のかを考慮してください。これは、ソースコード側にも影響が出ます。前述の「ViewBag」と「ViewData」の使い分けにも影響が出ますし、nullチェックや型変換といったソースコードの全域に影響があり、継続的インテグレーションにも大きな影響があります。実際に例を見ていきます。
• #12: たとえばサンプルのような階層型の設置値をresxで定義した場合、階層化の表現が非常に複雑になります。Excelなどで管理していて、ワークシート関数などを使ってコードを自動生成している場合は、なおさら継続的インテグレーションが困難になります。
• #13: resxファイルはWTI Converterなどで変換可能ですので、Visual Studio Codeで設定値を使いたい場合は、Jsonファイルに変換して利用することができます。WTI Converterは、非常に豊富な種類の変換ができます（画面左）ので、継続的インテグレーションのエコシステムに組み込むことも可能です。
• #14: オプションズパターンが設定値の関心ごとの分離に適している理由のひとつはオブジェクト表現です。オブジェクト表現は最終的にプリミティブデータの集合になるまで階層的に表現されます。ApplicationContextの場合、Pagesプロパティは文字列型の集合体であるPageオブジェクトの配列でプリミティブ表現できます。一般的な設定値の多くはキーと値のペアで表現できますが、関心ごとを表現する場合はほとんどのケースでオブジェクト表現が必要になります。 【クリック】今回のグローバリゼーションへの流用では、グルーピングは日本語文字列と英語文字列ということになります。関心ごとの分離とはページごとの分離などが一例に挙げられます。
• #15: 以前ドットネットラボでDomain Driven Designのお話をした際に、バリューオブジェクトという概念を解説しました。特定の型のインスタンスに入っているデータによって一意性が発生するオブジェクトで、たとえばシネマコンプレックスのスクリーンなどは「何月何日何時」の「スクリーンN番」で「上映作品」が一意に決まります。オプションとして席数とか音響設備、非常口の数などがあった方がオブジェクトの形としては理想的なので、上映作品やスクリーンオブジェクトをDomain Driven Designでエンティティ表現してもいいのですが、鑑賞者にとっては優先度の低い属性です。おそらく関心ごととしては「何月何日」の「何時ごろ」の「上映作品」の3つです。ユースケースとしては、日時を優先したいケースと上映作品を優先して別の候補日を見たいケースがあります。つまり「何月何日」「何時」「スクリーン番号」「上映作品」といった属性を持つバリューオブジェクトで十分一意性を保証でき、映画を鑑賞する人に向けたアプリケーションを作成することができます。映画を鑑賞する人に向けたアプリケーションというサブドメインの上映作品検索というバウンダリーコンテキストには検索対象のバリューオブジェクトだけ実装するというサービス設計が可能です。 【クリック】もちろん、シネマコンプレックスの予約システム管理側のバウンダリーコンテキストには、上映作品エンティティやスクリーンエンティティがあって、正規化されたリレーショナルデータベースを永続化層に持つマイクロサービスで実装され、ステートフルミドルウェア上で上映作品検索サービスとのステートマシンが形成されます。 【クリック】映画検索のようなデータセントリックなユースケースでは、ポリグロットパーシステンスの概念を採用したドキュメントスキーマDBを永続化層に持つマイクロサービスを作成することができます。適材適所の永続化層の設計を行えば、上映作品検索サービスでエンティティ表現された場合よりも高速に検索できることが容易に想像できると思います。
• #16: カプセル化として分離しているのは各ページの層までの部分になります。構成する属性が同じで、入っているデータによって一意性が決まるバウンダリーコンテキストの意味合いで分離されています。 【クリック】一方、各ページの下位の層は、それぞれが構成する属性が異なり、関心ごとによって分離しています。このバウンダリーコンテキストは業務の結果の記録なので、正規化されておらずドキュメント・スキーマをサポートするDBに保持されるように設計します。検索ページで検索条件が増えてもホームや個人情報のページのグローバリゼーションには影響しません。
• #17: オプションズ・パターンによるグローバリゼーションの実装の説明をします。まずは細かなところよりも実装の流れをつかんでください。
• #18: Visual Studio Codeを開いてターミナルを開きます。ターミナルを最大化してから、ここでlistオプションを使ってテンプレートの一覧を確認してください。作業ディレクトリを作成してカレントディレクトリにします。そこでRazor Pagesをdotnet newしてから、Visual Studio Codeでそのフォルダを開きます。
• #19: まずは、appsettings.jsonに日本語と英語のテキストを追加します。サンプルは私のMicrosoft MVPのプロフィールの本日の実績のところにGitHubのURLが載ってますのでそこを参照してください。
• #20: ポイントとしてはJapanese-Pages-Search-Areas-ControlLavelsなどのように階層化してある部分です。英語も同じ構造で設定しています。
• #21: Jsonの用意が終わったら受け取るためのクラスを作ります。ApplicationContextクラスを作っています。クラスの階層が深い部分でrecordで設定してある構造体があります。 【クリック】そのクラスを使ってProgram.csで設定ファイルを読み込んだサービスを提供するようにしています。
• #22: ポイントはrecordの部分になります。これが先ほど説明したデータセントリックな検索ページの構造体になります。
• #29: OptionsパターンはWeb AppやAPI、MVCはもちろんですが、.NET全般に利用できる機能です。本日お話したOptionsパターンの設計概念は、マイクロサービス、ポリグロットパーシステンス、ドメインドリブンデザインと非常に親和性の高い機能です。
• #30: 例としてグローバリゼーションが説明しやすかったのでスペイン語の追加を行っています。
• #31: ここでのポイントは英語と日本語のセクションを読み込んでいた部分について、セクションではなく全体を読み込むように変更しています。
• #32: View側を作成します。
• #33: 選択リストが変更されるとフォームをPOSTして、サービス側でリクエストから取得した言語指定を使った「configuration.GetSection(ApplicationContext.Japanese).Bind(Context)」などで切り替えることが可能です。