作成するアプリケーション
サンプルでは、旅費精算書を例にした帳票アプリケーションを作成します。帳票作成の業務アプリケーションでは、帳票の様式がWordやExcelで定義してある会社や学校などが多いので、サンプルプログラムでは、テンプレートとなるExcelファイルにプレースホルダを設定し、データベースの値をプレースホルダに埋め込んでからクライアントにダウンロードするといったシナリオを例にしています。このシナリオは、ユーザ自身がテンプレートを編集できるため、保守工数も軽減します。全3回で以下のようなアプリケーションを作成します。
- 旅費申請データフロー：
ユーザー→Silverlightアプリケーション配信サイト→Azureのデータストア
- 旅費承認データフロー：
ユーザー→AzureのASP.NETアプリケーション→Azureのデータストア
- 承認旅費参照データフロー：
Azureのデータストア→Silverlightアプリケーション配信サイト→ユーザー
- 帳票ダウンロードデータフロー：
Silverlightアプリケーション配信サイト→ユーザー
- Silverlightアプリケーションから旅費申請をし、Azure上のデータストアに申請情報を格納します。
- Azure上のASP.NETアプリケーションで携帯電話から承認します。
- 承認された申請は、Azureからデータサービスとして提供され、SilverlightアプリケーションがAzureのクライアントとして、承認済みの旅費精算書を作成します。
- Silverlightアプリケーションは、サーバーに作成された承認済み旅費精算書の一覧を表示し、ユーザーは一覧から申請書をダウンロード／印刷します。
第1回の今回は、Azure部分の解説は行わず、アプリケーションの全体像を作ってしまいます。後続の解説で、今回作成したVisual Studioソリューションを改造し、Azureに対応していきます。
今回のSilverlightの役割
データベース連携を行うことの多い業務アプリケーションでは、データアクセスレイヤーから正規化されたリレーショナルデータベースなどに接続して、取得したデータを業務ロジックで扱いやすいようクラスとして準備します。これをインピーダンスミスマッチの解消と言います。さらにビジネスレイヤーで加工して、概念モデルというアプリケーションの画面に近い形のデータにします。また、ワークフローなどを構築する場合もあります。
この際に、本来プログラマーが注力したいのは、ビジネスレイヤーの構築であって、業務を理解して業務ロジックを実装することです。しかしながら、実際にはデータベースアクセスやクエリ、トランザクション制御といった部分も実装しますし、UI側の例外処理に伴う視覚制御やユーザー操作にインタラクティブに反応する視覚効果などデータベースアドミニストレーターやデザイナーに任せるべき部分についても工数を割く必要があります。
Azureアプリケーションを作成する場合も同じです。Azureアプリケーション作成の際のUIとAzureの連携部分やAzure特有のロール、ストレージの管理、またWCF通信、エンドポイントの制御など、業務ロジックとは関係のない部分の構築に多くの工数を割くことになります。
とかくUIの派手なプレゼンテーションに注目されがちなSilverlightですが、このようなデータ通信を含む通信周りの構築工数を軽減することにも長けていますので、SilverlightとAzureを併用することは、そうでない場合に比べ、業務ロジック以外の機能の作成作業を軽減することができます。また、Silverlight部分をアウトソーシングするとか、複数の会社やメンバーで協業してアプリケーションを作成することも可能です。
レイヤー分割は本当に必要かを検討する
ただし、アプリケーションのレイヤー分割というのは、複数メンバーでのシステム構築における作業分割を想定した場合の観点です。レイヤー分割する必要のないアプリケーションもありますし、コミュニケーション不足や技術力の乖離により、クライアントとサービスの担当者間で設計の方向性を共有できないようなプロジェクトもあります。レイヤー分割により、著しく開発効率を低下させることもあるので、皆さんのプロジェクトにマッチした分割を計画してください。
総合的な観点からアプリケーションのレイヤー設計の指針を明確にすることが本連載の目的です。
