特集 業務Webアプリの作り方の基礎（後編） 基本的な業務Webアプリの開発手順 尾崎 義尚 Microsoft MVP for Development Tools - Visual C# Oct, 2005 - Spt, 2008 2008/03/18
Page1 Page2

■4. 各層の開発

　前回説明した内容を踏まえて、Visual Studio 2005を使用した3階層業務Webアプリを開発していこう。

●4.1. ソリューションの構成

　さて、論理的な3階層を説明したが、実際にアプリを開発するためには、最初にVisual Studioで「プロジェクト」とそれを束ねる「ソリューション」を構成する必要がある。まず、Webアプリの構成について考えてみよう。

　中規模以上のシステムでは、全体を複数のサブシステムに分けることが多い。このとき、Webアプリの構成として筆者がお勧めするのは、Webアプリ1つに対して、サブシステムごとのクラス・ライブラリという構成である。

論理3階層とプロジェクト構成のイメージ

ソリューションが1つのWebアプリ・プロジェクトと複数のクラス・ライブラリで構成され、クラス・ライブラリがビジネス・ロジック層とデータ・アクセス層にまたがっている。

　Webアプリでは、ログインされたユーザーを特定するための認証情報やアプリ内で共通のデータを保持することが多いため、メモリ上でデータを共有できるように単一のWebプロジェクトで作成することをお勧めする。ただし、プロジェクト規模が大きくなってきたときは、複数のサブシステムを1つのWebプロジェクトで作成してしまうと、開発時に必要なメモリ量が増えたり、ビルドが遅くなったりといった問題が発生する。そのため、開発時には共通のファイルとサブシステム・フォルダのみの構成にしておいて、開発者が自分の作成しているサブシステムの開発に注力できるようにしておき、最後に統合して結合テストを行い、リリースするという構成を採るとよい。

　次にビジネス・ロジック層とデータ・アクセス層であるが、この2つの層は別々のプロジェクトでもよいし、単純にフォルダを分けるだけという構成でもよい。これは階層の分け方（アーキテクチャ）にも依存する。例えば、ビジネス・ロジック層とデータ・アクセス層を別々のサーバに配置して負荷分散を行う場合には、アセンブリが分かれている必要があるため、プロジェクトを分けて作成する。プロジェクトの構成はアプリの特性やサーバ構成に応じて検討してほしい。

　それでは、まずはソリューションを作成しよう。Visual Studioのソリューションは、最初のプロジェクトを作成したときに同時に作られる。まずは、Webアプリのプロジェクトを作成するが、本稿ではソリューションの作成手順やクラス・ライブラリの作成手順は説明しない。基本的なWebアプリの作成手順については、VB6開発者のためのASP.NET開発入門を参考にしてほしい。

　次にビジネス・ロジック層のクラス・ライブラリをソリューションに追加する。最終的には以下のようなイメージのソリューションができるはずだ。

ソリューション構成のイメージ

Webアプリが1つ、ビジネス・ロジック・プロジェクトが複数存在している。また、Webアプリの中でサブシステムのフォルダが作られていて、サブシステムで必要なWebページが作成されている。

　このように1つのWebアプリをサブシステムごとのフォルダに分けて管理して、Webアプリからサブシステムのクラス・ライブラリ・プロジェクトを参照する。また、サブシステムのクラス・ライブラリでは、DataAccessフォルダを作成して、データ・アクセス層のコンポーネントを作成するようにすることで、ASP.NETのソリューションで3階層のアプリを作成することができる。

　それでは、実際にアプリを作成していこう。

●4.2. プレゼンテーション層の開発

　プレゼンテーション層の開発は非常に地味な作業である。コントロールを配置して、デザインを調整して必要な画面を作っていく。デザインが終わると次に裏側（コードビハインド）の記述を行うが、ここで必要なのは画面上の振る舞いや入力値のバリデーション、ビジネス・ロジック層への受け渡しなど比較的単調な作業である。

　プレゼンテーション層は、エンド・ユーザーとシステムとの境界である。表示はエンド・ユーザーの要望によってさまざまに変化させられる柔軟性を持たせておく必要があるが、裏で動くビジネス・ロジックは業務要件に従ってきっちりと作成しておく必要がある。プレゼンテーション層はこの2つの要件のつなぎであるともいえる。

　例えば、日付は「H19/11/01」のように和暦で表示してほしいというエンド・ユーザーの要望があったとする。.NET Frameworkでは、入力された文字列を日付として直接扱うことができないため、それをDateTime型に変換して処理する必要がある。日付に限らずWebページから入力されるのはすべて文字列である。金額や数量などの数値を入力する個所は、ASP.NETで提供されているRegularExpressionValidatorコントロールなどを使用して入力値のバリデーションを行う。その後、システムが処理しやすい型に変換して使用するようにする。

　プレゼンテーション層を開発するとき、「ユーザー表示」と「システム処理」の2面で考えると分かりやすい。ユーザー表示面では、エンド・ユーザーの要望によってどんな形式にでも変更できるが、システム処理面では、システムが処理しやすいDateTimeやDecimalなどの型に変換して処理を行い、ビジネス・ロジック層への引き渡しを行う。この2面を意識して開発することで、プレゼンテーション層でやるべきことが明確になる。

プレゼンテーション層の2面

エンド・ユーザーの要望に従って表示するユーザー表示面と内部処理やビジネス・ロジック層への受け渡しを行うシステム処理面の2面で考えるようにする。

　ユーザー表示部分は、エンド・ユーザーの目に直接触れるため、変更の要望が最も多い。ユーザー表示面とシステム処理面をきちんと分けておくことで、システム処理やビジネス・ロジックの変更を最小限に抑えて、表示だけを変更することが可能になる。

●4.3. ビジネス・ロジック層の開発

　ビジネス・ロジック層は、ソリューションの構成で説明したようにサブシステムごとのクラス・ライブラリとして作成する。クラスの分割に自信がない場合は、前編の「クラス分割のコツ」で説明したように、1つの業務について1つのクラスを作るようにするとよい。また、業務処理のメソッドは「命名のコツ」で説明したようにApply（申請）、Order（注文する）などの業務で使用される名前を使用して作成する。

　メソッドの内部では、「メソッド分割のコツ」で説明したとおり、業務処理の流れを記述して、データベースの登録には、データ・アクセス層のクラスを呼び出すようにする。

　業務アプリのもう1つの重要な要素としてトランザクション制御がある。例えば、これまでに解説してきたような受注処理の一連の流れは、どこか1つでも失敗すると業務として成立しないため、1つのトランザクションとして処理する必要がある。また、どこかの処理が失敗したときには、変更を元に戻すためのロールバックを実行する必要がある。データにかかわることなのでデータ・アクセス層で行うべきではないかと思うかもしれないが、どの処理がどの処理と関係があるかを考慮して設計できるのはビジネス・ロジック層だけであるため、トランザクション制御はビジネス・ロジック層で行う必要がある。トランザクション制御は、業務アプリにおいて重要な要素だということは理解しておいてほしい。

　では、最後にデータ・アクセス層の開発について解説していこう。

●4.4. データ・アクセス層の開発

連載：Visual Studio 2005によるWindowsデータベース・プログラミング

　データ・アクセス層の開発は、本稿ではビジネス・ロジック層と同じクラス・ライブラリのプロジェクトとして作成することにする。

　Visual Studio 2005でデータ・アクセス層を開発するには、テーブルアダプタ（TableAdapterコンポーネント）を使用するのが最も簡単である。テーブルアダプタを使用することで、テーブル操作などデータベースに必要な処理を.NETプログラム言語からアクセス可能なメソッドとして作成することができる。また、デザイナを使用してほとんどの操作ができるため、SQL文を記述しなくても、ほとんどのテーブル操作を実現することができる。

テーブルアダプタのイメージ

テーブルアダプタで自動生成されたメソッドからSQL文やストアド・プロシージャが実行されてデータベース上のデータにクエリを実行している。また、クエリの実行結果が保持されるデータテーブル（DataTableオブジェクト）も自動的に作成される。

　では、実際にテーブルアダプタの作成手順を説明していこう。テーブルへの単純なアクセスであれば、ドラッグ＆ドロップだけで作成できる。まず、プロジェクトにデータセット（DataSetクラス）を追加する。

データセットの追加

［新しい項目の追加］ダイアログから、プロジェクトにデータセットを追加しているところ。

　追加したデータセット（のフォーム・デザイナ）に対して、［サーバー エクスプローラ］からテーブルをドラッグ＆ドロップする。これだけで、テーブルへの基本的なCRUD操作を行うためのメソッドが用意される。なおCRUD操作とは、Create、Read、Update、Deleteの頭文字を取ったものでSQLのINSERT、SELECT、UPDATE、DELETEに対応する。

テーブルアダプタの作成

［サーバー エクスプローラ］からテーブルをドラッグ＆ドロップするだけでデータテーブルとテーブルアダプタが作成されている。

　テーブルへのINSERT操作や全データを取得するSELECT操作だけなら、これだけでも十分なのだが、実際の業務アプリではもっと複雑なクエリが必要になる。Visual Studio 2005ではそういった複雑なクエリを作成することも可能だ。

　これには、データセットのデザイナ上で右クリックして、コンテキスト・メニューから［追加］−［TableAdapter］をクリックし、表示される［TableAdapter構成ウィザード］で接続先などを選択していき、［SQLステートメントの入力］のページでSQL文を入力すればよい。

　SQL文の入力では、次の画面の［クエリ ビルダ］を使用すると便利だ。SQL文の知識があまりなかったとしても、［クエリ ビルダ］を使用することで複雑なクエリを作成することができる。

複数テーブルを結合したクエリの例

［クエリ ビルダ］を使用することで、複数のテーブルからデータを取得するクエリや、外部結合など複雑なクエリをGUIで作成することができる。

　ここまでに解説したように、基本的なテーブル操作であれば、ドラッグ＆ドロップでテーブルアダプタを作成することができるし、一覧表示で使用するような複雑なクエリでも、［クエリ ビルダ］もしくはSQL文の直接入力で簡単にデータ取得のロジックを作成することができる。

　このようにして作成したクエリをストアド・プロシージャとして登録したり、すでにDBサーバに登録されているストアド・プロシージャをメソッドとして作成したりすることもできるが、［クエリ ビルダ］で編集ができなくなってしまうため、パフォーマンスなどの問題がない場合は、SQL文として作成しておくことをお勧めする。

　また、受注ステータスの変更など、テーブルの一部だけを更新する操作や、注文のキャンセルによる明細データの複数行削除など、自動生成されるクエリ操作以上の処理が必要な場合には、テーブルアダプタにメソッドを追加することができる。

　これにはテーブルアダプタを右クリックして、コンテキスト・メニューから［クエリの追加］を選択する。［クエリの構成ウィザード］が表示されるので、追加したいクエリの種類を選択していく。

［クエリの構成ウィザード］が表示される

テーブルアダプタにメソッドを追加する

より複雑な条件のSELECT文やキー項目以外を条件にしたDELETE文、一部のデータのみを更新するUPDATE文などが作成できる。

　このようにクエリの追加でテーブルに対するさまざまな操作を追加することができる。一部のデータを更新するようなUPDATE文や、ある条件で削除を行うようなDELETE文など、自動的に作成されないクエリ操作を必要に応じて追加することができる。例えば、受注IDを指定して受注明細データを削除するような場合に便利だ。

　このように作成されたテーブルアダプタのクエリは、クラスのメソッドとして呼び出すことができるようになる。受注IDから受注明細を削除する操作を見てみよう。

using (OrderDetailTableAdapter adapter         = new OrderDetailTableAdapter()) {   adapter.DeleteByOrderId(orderId); } Using adapter As New OrderDetailTableAdapter   adapter.DeleteByOrderId(orderId) End Using

テーブルアダプタのクエリをメソッドとして呼び出すサンプル・コード（上：C#、下：VB）

　このように、テーブルアダプタを使用することでデータベースへのクエリをメソッドとして呼び出せるようになる。

　また、テーブルアダプタにクエリ以外の処理を追加することもできる。

　データテーブルをダブルクリックすることで、データテーブルの部分クラス（Partial Class）を作成することができる。部分クラスとは、1つのクラスを作成するのに複数のファイルでメソッドを実装できる技術であり、ここではVisual Studioによって自動生成されたデータテーブル（のクラス）に、自分で記述したメソッドを追加できるようになる。

　これによって、データ・アクセスに関連する処理をデータテーブルの中にまとめることができる。つまりビジネス・ロジック層では、データベースの構造を意識させないように作成して、データ・アクセス層であるデータテーブルの部分クラスで各テーブルに対するデータ処理を記述できるのである。ただし、ビジネス・ロジックに関連する部分を含めてしまうことも可能なため、データ・アクセスの処理なのか、ビジネス・ロジックの処理なのかをきちんと意識して作成することが重要である。

■5. まとめ

　本特集では前・後編にわたって業務Webアプリの一般的な開発で考慮するべき点や考え方について解説してきた。業務Webアプリの開発では、すべての層で業務を意識することが重要である。また、層の役割を意識して開発することで、どこに何が記述されているのかが特定しやすくなり、バグの修正やメンテナンスが容易になる。

　本特集で解説した内容が、業務アプリについて考えるきっかけになり、今後のアプリ開発の役に立てれば幸いである。

INDEX
	［特集］
	業務Webアプリの作り方の基礎（前編）
	業務アプリ開発で失敗しないコツ
	1．クラス分割のコツ、メソッド分割のコツ
	2．命名のコツ、コメント記述のコツ
	業務Webアプリの作り方の基礎（後編）
	基本的な業務Webアプリの開発手順
	1．業務Webアプリの構造パターン
	2．各層の開発

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）