Introduction to Application Architecture on ASP.NET MVC

（仮）

福井 厚 Atsushi Fukui ( @afukui )

.NET FEST 2015

2015.9.26

本セッションの内容について

• 本セッションの内容は、発表者個人の経験に基づく個人的な意見であり、所属する団体、組織の公式な見解、発表ではありません。

• あくまでスピーカー本人の経験に基づく内容となっていることをご承知おきください。

自己紹介

• 福井 厚 （ふくい あつし）

• @afukui

• メーカー系サポートでOS、言語などを担当後、ソフト開発会社でC/S型業務パッケージ、C/C++用ライブラリ等の開発を経験。94年にSIerへ転職し業務アプリケーションを多数開発、データベース設計支援、COM+による分散フレームワークの開発などを担当。外資系SIerに転職しソリューションアーキテクトとして.NETによる企業向けフレームワークの構築などを担当。2011年3月株式会社アークウェイに入社、プリンシパル コンサルタントとして企業向けソフト開発コンサルティングを行う。

2015年7月よりアマゾンデータサービスジャパン株式会社で Solutions Architect として活動。

• 2008年8月、Microsoft Certified Architect for Solutions Certification (MCA) に認定される。

• マイクロソフトMVPアワード受賞歴11回（2015年7月にMVP 終了）

個人ロール年表

1980 1990 2000 2010

カスタマサポートフィールドSE

ソフトウェアデベロッパー

純国産システムエンジニア

外資系アーキテクト

開発コンサルタント

クラウド ソリューションアーキテクト

アジェンダ

• コンテキスト

• アーキテクチャとは何か

• アーキテクチャ検討ポイント（ASP.NET MVC 編）

• まとめ

コンテキスト

• 本セッションのテーマ• ASP.NET MVC アプリケーションのアーキテクチャ ポイント

• 標準で提供されている機能に絞って紹介

• 用語（アーキテクチャ）• このセッションではアーキテクチャを主にソフトウェア アーキテクチャの意味

で使っています。

• 対象• 企業向けアプリケーション開発を行っているアーキテクト、設計者、開発者

• レベル 200 のイントロダクションです。

• 正解を教えるセッションではありません。

アーキテクチャとは何か

アーキテクチャとは ISO/IEC/IEEE 42010（IEEE 1471改定版）

http://www.iso-architecture.org/ieee-1471/cm/

アーキテクチャは階層構造• 企業全体のアーキテク

チャから実装コードまですべてがアーキテクチャ

アーキテクチャ ≠ フレームワーク

• フレームワークを利用することがアーキテクチャを作ることではありません

• 目的と制約に従って必要な品質特性を満たすソフトウェアの構造を定義し共通利用する機能を提供するものがアーキテクチャ• 従って目的と制約が異なれば違うアーキテクチャが必要です。

正しいアーキテクチャを構築するために

• 要求定義

• フィーチャーの抽出

• 実装検証

アーキテクチャ要求定義

• 目的の整理• アーキテクチャを構築する目的は何か• ステークホルダーごとに要求は異なる• アーキテクチャが解決すべき課題は何か

• 満たすべき品質特性• 重視するソフトウェアの品質特性は何か

• 制約• 組織、環境、過去の資産、開発者のスキル、政治的

なしがらみなど、どのような制約があるか

• 利用技術の選定• 長く使える技術を見極める

ソフトウェア品質特性 ISO/IEC 25010（IEEE9126 の改定）

• どの品質特性と副特性を重視するか

© 2015 iso25000.com

フィーチャーの抽出

• 目的に従ってアーキテクチャが提供すべきフィーチャーを抽出

• オプションとマンダトリの整理

• フィーチャーと品質特性のマッピング

• 抽出したフィーチャーで重視する品質特性を満たしているかを確認する

実装検証

• 抽出したフィーチャーがアーキテクチャ要求を満たしていることを検証

• セキュリティ• 想定されるケースでの認証、認可は必須

• パフォーマンス• パフォーマンスは測るまで誰にも分らない

• 限界点を知る

• システムにとって最も難しい機能から検証する• クラウドの新機能活用や新しい認証基盤の利用など、過去にやったことがな

いものは失敗するかもしれないことを前提に必ず検証する

アーキテクチャ検討ポイントASP.NET MVC 編

アーキテクチャ検討ポイント

• UIデータバインド

• バリデーション

• 例外処理

• 認証・認可

• データアクセス

UI データバインド

• サーバーサイド レンダリング• ASP.NET MVC では View を生成する処理

• Razor テンプレートをもとに動的にHTML を生成

• クライアントサイド データ バインディング• クライアント JavaScript から非同期でデータを取得

• HTML DOM にデータをバインド

UI データバインド

Web Server /App Server

Browser DB Server

サーバーサイド レンダリング

• 動的にHTMLページを組み立て• データアクセスした結果をページの挿入• 生成したページを送信

生成したHTML

HTTP GET リクエスト

• 生成されたHTMLをブラウザで表示

UI データバインド

Web Server /App Server

Browser DB Server

クライアントサイド データ バインディング

• Web サービスを公開• データアクセスした結果をJSONとして返

却

JSONデータ

ajax GET リクエスト

• 取得したJSONデータをHTMLDOMにバインド

UI データバインド

メリット デメリット

サーバーサイドレンダリング

• 単一のプログラミング パラダイム

• サーバーサイドでのみ実現可能な処理• 認証、認可• ブラウザの言語判定

• 状態情報をサーバー側で保持するためサーバーメモリを消費

• 負荷分散時の状態情報の保持でパフォーマンスが低下

• リクエスト数の増加でレンダリング処理の負荷が増大

クライアントデータバインド

• 状態を HTML DOM に保存することでエラー発生時に再送が可能

• サーバーサイドのメモリを節約

• レンダリング処理をクライアント側で行うため、サーバーの負荷を削減

• 非同期のためデータバインドが遅延する可能性あり

• 複数のプログラミング パラダイムが必要

Demo

バリデーション

• クライアントサイド バリデーション• jQuery Validation

• サーバーサイド バリデーション• ModelState プロパティ

• Entity クラスの Attribute

Demo

例外処理

• 例外は原則として集約的に捕捉して処理する

• Web API の例外処理• Web API 2.2 Global Error Handling

• Web API のパイプラインで発生したすべての例外を補足

• 以下のインターフェイスを継承• IExceptionLogger

• IExceptionHandler

• それ以外の例外処理• Global.asax の Application_Error イベントハンドラ

• IIS、ASP.NET で発生した例外を補足

Demo

認証・認可

• Windows 認証• IIS の統合認証を有効化

• Web.config の system.web/authentication の mode=“window”

• Cookie Authentication• OWIN Authentication メソッド

• Cookie Authentication （Form 認証）

• External Sign in Cookie （Oauth 2.0 認証）

• Two Factor Sign In Cookie

• Organization Authentication• Azure AD ドメイン

• オンプレミス ADFS

External Sign in 認証 手順 (google IDの例）

External Sign in 認証 手順 (google IDの例）

External Sign in 認証 手順 (google IDの例）

External Sign in 認証 手順 (google IDの例）

External Sign in 認証 手順 (google IDの例）

External Sign in 認証 手順 (google IDの例）

External Sign in 認証 手順 (google IDの例）

ClientIId、Client Secret が生成される

External Sign in 認証 手順 (google IDの例）

• Startup.Auth.cs 内の処理を有効化• 利用する Open ID のコメントを外し、Client Id、Client Secret を追加

app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions(){

ClientId = “your client id",ClientSecret = “your client secret"

});

Demo

データアクセス

• Entity Framework を活用• JSONで集約オブジェクトのコレクションを追加すればEFが自動的に親子テー

ブルにデータを追加してくれる

• Entity Framework 7 に備えて• Code First From Database を選択

• EF7 では EDMX が無くなる

• DBを変更した場合は Entity クラスを生成し直し

データアクセス

• テーブル間のリレーションシップから生成されるナビゲーション プロパティの相互参照に注意• Costomer と Order など相互にナビゲーション プロパティを持つものは、デ

フォルトのJsonシリアライザの設定で循環参照例外が発生

• WebApiConfig.cs の Register メソッドに Json.NET のシリアライザ設定を変更する

config.Formatters.JsonFormatter.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore;

Demo

まとめ

• アーキテクチャは容易には変更できないので長いスパンで利用できる技術を選択する

• アーキテクチャの選択は常にトレードオフがある

• 選択した理由を説明できることが重要

Q & A

ご清聴ありがとうございました