Application Architecture for .NETの概要

連載：アプリケーション・アーキテクチャ設計入門 - ＠ITより抜粋。
2003年の記事だが内容は今も有効。

ユーザー・インターフェイス・コンポーネント

データの入力時には以下の処理をする。

    • データを取得する
    • ツールやガイドでデータの登録を助ける
    • ユーザーの操作を解釈して、Controllerを呼び出す
    • Controllerは、ユーザー・プロセスを開始したりユーザー・プロセスの状態を変えたりすることで、ユーザー・インターフェイス・コンポーネントの表示内容を変更する
    • 入力可能なデータの型を制限する
    • 入力されたデータを検証する
    • 入力されたデータを、その後に控えるコンポーネントに都合が良いようにマップしたり変形したりする

データの出力時には以下の処理をする。

    • ビジネス･コンポーネントまたはデータアクセス・ロジック・コンポーネントのデータを取得して表示する
    • 表示フォーマットを決める
    • 表示データをローカライズする（リソース文字列などによる）
    • ビジネス･エンティティに関係するデータを表示する。ビジネス･エンティティの実装がADO.NETのDataSet型を使用していれば楽だが、独自のビジネス･エンティティ・コンポーネントならば追加のコードが必要である
    • アプリケーションのステータス情報を表示する
    • ユーザー・インターフェイスの外観を、ユーザー設定や使用デバイスに応じてカスタマイズする
  • 推奨

Windowsアプリケーションの場合

    • 同時に開かれるフォーム間でデータを同期するためには、データ連結を使う
    • 画面遷移はコードに直接記述せずに、ユーザー・プロセス・コンポーネントを利用する
    • フォームでも例外をキャッチする
    • サーバのコンポーネントを呼び出す前に、ユーザーの入力を検証して結果をユーザーに見せる
    • カスタム・ユーザー・コントロールのインターフェイス（プロパティやメソッド）は必要最小限だけを公開する
    • イベント・ハンドラに直接Controller機能を実装しないで、最低限メソッドを別にする

Webアプリケーションの場合

    • カスタムエラー・ページを用意し、global.asaxでアプリケーションのエラーを処理する
    • データの検証はクライアント側だけではなく、ほかのページに遷移する前にサーバ側でも行う
    • カスタム・ユーザー・コントロールのインターフェイス（プロパティやメソッド）は必要最小限だけを公開する
    • ページ固有の状態を保持するためにはビューステート（ページのViewStateプロパティ）を使う
    • ページのリダイレクトはController機能が直接するのでなく、必ずユーザー・プロセス・コンポーネントで行う
    • イベント・ハンドラに直接Controller機能を実装しないで、最低限メソッドを別にする

モバイルアプリケーションの場合

    • どちらの場合も基本的にデスクトップPC向けと同じだが、モバイル・デバイスの場合は特に入力データの検証に注意を要する。Webであれば、クライアント側での検証には多くを期待できないし、スマート･デバイスであれば、Visual Studio .NETの「スマート・デバイス拡張」には、検証コントロールが含まれていないためである。

（Office製品をUIとする）ドキュメントの場合

    • ドキュメント・ベースのユーザー・インターフェイスにおいても、入力データの検証には注意が必要である。データ型を限定するだけでなく、データをチェックしてエラーを表示する機能を実装する場合も多いだろう。

ユーザー・プロセス・コンポーネント

  • 特徴
    • トランザクションを開始しない。トランザクションに参加したり投票したりもしない
    • ビジネス・ロジックに関連する内部データとユーザー・プロセスの内部状態を保持し、必要に応じて永続化する
    • 個々のステップとして遷移する画面は、コードに直接書くか、構成ファイルなどのメタデータから動的に取得する
    • 内部データを初期化させるために、ビジネス・コンポーネントやデータ･アクセス・ロジック・コンポーネントを呼び出してもよい
    • メニューを管理するカスタム・ユーティリティ・コンポーネントから開始されてもよい
  • 役割
    • ユーザー・インターフェイスの構成要素を、データフローや制御ロジックを変えずにインタラクション（ユーザーとのやりとり）の順序制御に対応付ける
    • ユーザー・インターフェイスのセッションを、関係するユーザー・プロセスに対応付ける
    • インタラクションの概念的な順序を実装やデバイスから独立させる
    • 例外がユーザー・プロセスに悪影響を及ぼさないようにする
    • ユーザー・プロセスがどのように状態を変えていったのかを保持する
    • ユーザー・プロセスによって変更されたビジネス関連データを保持する
    • ユーザー・プロセスに中断と再開の機能を加える
    • ユーザー・プロセスが完了するときに、ビジネス・コンポーネントを呼び出す
  • 推奨
    • 設計時に、ユーザー・プロセスをコンポーネントとして分離すべきかどうかを検討する。ユーザー・プロセス・コンポーネントの設計は簡単な作業ではない
    • ユーザー・プロセス・コンポーネントはシリアライズ可能にして、ビジネス・プロセスとは別個に永続化できるようにする
    • ユーザー・プロセスをどこに保存するのかを検討する。クライアントがオフラインで動作するのか、障害が起きた場合にユーザー・プロセスを復元すべきなのか、別のコンピュータでプロセスを再開することがあるのか、などが判断基準となる
    • ユーザー・プロセス・コンポーネントで例外をとらえ、ユーザー・インターフェイスに渡す

書きかけ・・・