本稿はActiveReportsの旧バージョンを用いた内容となっています。最新版に基づいた記事は連載の目次「5分でわかるActiveReports帳票」をご参照ください。
はじめに
ActiveReports for .NET（以下ActiveReports）は、Visual Studioと統合された使いやすいレポートデザイナや、高機能なレポートビューア、多彩な出力形態をサポートする帳票作成コンポーネントです。
今回は、これまで紹介してきたActiveReportsの各機能をふまえて、帳票アプリケーションを設計するための手順について紹介していきます。
これまでの記事
- 第1回：5分で"もっと"わかるActiveReports帳票－ランタイムデザイナの開発
- 第2回：5分で"もっと"わかるActiveReports帳票－Visual Studio 2008に対応したActiveReportsの新機能
- 第3回：5分で"もっと"わかるActiveReports帳票－帳票完成時にチェックしておきたいポイント集
対象読者
- Visual Basic 2008またはVisual C# 2008を使ってプログラムを作ったことのある方。
- 帳票作成ツールに興味のある方。
必要な環境
開発ツール
- Visual Studio 2008
- Visual Studio 2005（※Windows Vistaで開発する場合はVisual Studio 2005 Service Pack 1 Update for Windows Vistaの適用が必要です）
- Visual Studio .NET 2003
クイックスタートの次は、アプリケーション設計
これまでの記事で紹介してきたように、ActiveReportsではVisual Studioに統合されたレポートデザイナへコントロールをドロップし、プロパティを設定するだけで、プログラムコードを書くことなく帳票アプリケーションに必要なほとんどの機能を実装することができます。
また、必要に応じてイベント処理コードを追加することで、帳票出力のさまざまなタイミングで出力プログラムの動きを制御することも可能です。プログラミングレスでもできることが多いため、帳票アプリケーションの開発経験が少なくても簡単に開発をスタートできるところは、ActiveReportsの大きな長所であると言えます。
小規模な帳票出力アプリケーションを開発する場合は、ヘルプやチュートリアルを参考にトライアンドエラー方式で開発していくのもよいでしょう。しかし、業務システムの帳票出力機能として、ある程度まとまった数の帳票を使用するアプリケーションを開発する場合は、必ずしも「素早く開発すること」だけがゴールになるとは限りません。
大規模なシステム開発の現場では、プロジェクトに参加する開発者が個別にアプリケーションを実装してしまうと、担当した技術者のスキル差によってプログラム品質のばらつきが発生してしまいます。また、品質は十分であったとしても実装方式が統一されていなければ、中長期的な視野で見た場合、メンテナンス性が低下して保守コストが増大してしまうことも考えられます。
このような問題を回避するためには、アプリケーションを開発する初期段階で共通の設計方針（ガイドライン）を定め、統一的な方法でアプリケーションを設計・開発する必要があります。
帳票アプリケーションの特徴と設計手順
それでは、設計方針を確認する前に、帳票アプリケーションの特徴について簡単にまとめておきましょう。
帳票アプリケーションとは、ひとことで言うと「データソースから抽出したデータを、帳票レイアウトによって書式付けし、所定のサイズを持つ用紙に出力する」アプリケーションです。つまり、帳票アプリケーションの機能を大きく分けて動作順に並べると、以下の3つになります。
- データソースからデータを取得する
- 取得したデータを帳票レイアウトに当てはめる
- 帳票レイアウトをレンダリングして、用紙に出力する
最初の「データソースから必要なデータを取得する」部分は、RDBMSやファイルなどに含まれるデータの中から必要なものを検索して、データを帳票として出力しやすい形に整える工程です。データソース側に定義されているフィールドをそのままバインドして使うことも多いのですが、場合によっては検索条件をつけて絞り込みをかけたり、データの型や並び順を修正するなど、データ量や型、書式を加工することもあります。この工程では、「データをデータソースからどのように切り出すか」を定義します。切り出されたデータのことを、ここでは「データモデル」と呼ぶことにします。
次の「取得したデータを帳票レイアウトに当てはめる」部分は、整形されたデータモデルの各フィールドと、レポートファイルに配置されたコントロールを対応付けるための工程です。ここでは帳票レイアウトの定義として、全体のレイアウトやセクションごとの出力構造とグループ化条件、出力項目の書式設定などについて定義します。
最後の「帳票レイアウトをレンダリングして、用紙に出力する」は、実際にプログラムを動かして、データモデルの各項目と帳票レイアウトを結びつけて出力コンテンツを生成し、規定のサイズを持つ用紙に割り付けていく工程です。ActiveReportsを利用して帳票アプリケーションを開発する場合、レンダリングと出力に関してはActiveReportsのレポートエンジンが担当してくれるので、この部分の機能は特に設計・開発する必要はありません。
つまり、ActiveReportsを利用した帳票アプリケーション開発において、帳票アプリケーションの設計は「データモデルの定義」と「帳票レイアウトの定義」の2つがメインになると言えます。この他にも、ユーザーの要件によっては「データの集計結果にエラーがあれば、帳票の生成を中止する」「帳票を出力した日時をデータベースに記録する」など、さまざまな機能を追加する必要があるかもしれません。
しかし、要求されたすべての機能を帳票出力アプリケーションとして一緒に実装してしまうと、各機能を個別に動作確認させることが難しくなり、またメンテナンス性も著しく低下します。
帳票出力そのものと関係の薄い周辺機能は、帳票アプリケーション本体とはいったん切り離して設計し、それぞれが完成してから連携する、という手順を取った方が得策です。
まずは帳票レイアウトを定義する
さて、ここまでは帳票アプリケーション設計の要素として「データモデルの定義」と「帳票レイアウトの定義」の2つがあると説明しました。
帳票が出力される順番で考えると、最初に取り組むのは「データモデルの定義」のようにも思えますが、実際には「帳票レイアウトの定義」を先に行う場合の方が多いのではないでしょうか。業務システム開発において、アプリケーションの画面イメージや出力帳票のレイアウトなど、ユーザーが直接触れる部分（ユーザーインターフェース部分）の仕様は、要求分析や基本設計など早い段階から具体的なイメージを作成してユーザーと仕様を確認しておく必要があります。
逆に、データモデルは開発者にとっては重要な設計情報ですが、ユーザー側にしてみれば「ちゃんと動いてさえくれればよい」という認識であるのが普通であり、必ずしも最初に考えなければいけない部分ではありません。本稿でも、データモデルの定義に先行して、帳票レイアウトの定義から考えていきたいと思います。
帳票レイアウトを構造化する
帳票レイアウトの作成は、ユーザーとの打ち合わせやヒアリングから帳票に出力したい内容や項目を洗い出すところから開始されます。ユーザーが単なるデータの羅列ではなく、デザイン性にも優れた帳票を望んでいる場合は、何度もレイアウトのラフを作ってユーザーとイメージを確認する必要があるかもしれません。しかし、サービスの利用明細や請求書など、ビジネスシーンに登場する典型的な帳票であれば、お決まりの「型」のようなものがある程度決まっていることも多いです。
また、開発案件の目的がまったくの新規開発ではなく既存システムの刷新であるような場合は、現在使われている帳票レイアウトをユーザーから提供してもらえることもあります。このような場合、レイアウト作成自体は楽になりますが、「なるべく既存のレイアウトと合わせてほしい」といった、別な形のリクエストを受けることもあります。
項目の洗い出しと大まかな配置を決めて帳票レイアウトのイメージが固まったら、次はこのレイアウトから出力構造を洗い出します。レイアウトをもとにして1セットの帳票を出力するときに、どの項目がどのようなタイミングで出力されるかを考えていきます。帳票レイアウトの構造化を考えるときは、ActiveReportsのレポートセクション構造に当てはめて考えるのが便利でしょう。
以下は、ActiveReportsで定義することのできるレポートセクションの一覧です。
- 帳票全体で、最初/最後に出力する項目（レポートヘッダ・レポートフッタ）
- 各ページで、最初/最後に出力する項目（ページヘッダ・ページフッタ）
- 集計グループごとに、最初/最後に出力する項目（グループヘッダ・グループフッタ）
- 繰り返し項目（Detailセクション）
帳票全体の最初と最後に出力されるレポートヘッダ/フッタや、ページの最初/最後に出力されるページヘッダ/フッタはプロパティグリッドで設定できる項目も少なく、特に複雑な部分はありません。一方で、グループヘッダ/フッタは、集計単位となるデータフィールドの指定やセクション出力前後での改行タイミング、出力グループのブロック化など、出力方法に関してさまざまな選択肢が提供されています。1つの帳票で複数のグループが入れ子になる場合は、重ね順についても定義しておいてください。
レイアウトの構造化がある程度まとまったら、次はその構造化された帳票レイアウトを使ってサンプルを出力し、改ページ位置などを確認しておきましょう。なお、ユーザーとレイアウトについて打ち合わせをする場合、全体が1枚で収まるデータ量の少ないサンプルで確認してしまいがちですが、2ページ目以降はどのように出力されるか、グループごとに改ページを入れるか、などについても確認しておくのがよいでしょう。
出力項目の定義と配置
帳票レイアウトの構造化が終わったら、次は各セクションに配置する出力項目を定義します。
アプリケーション設計の段階では出力項目の論理名だけを定義することが多いと思いますが、ここでは論理名だけでなく物理名も定義しておくことをお勧めします。「商品名」であれば「ProductName」でも「SHOHIN_MEI」でも、論理名に対応する名称であれば何でもよいので、物理名を定義しておきましょう。物理名を定義しておくと、ActiveReportsのコントロールの名前としてそのまま使うことができるので便利です。
実際の開発現場では、出力項目の定義として「論理名とデータベースのフィールド名だけ」しか指定されていないようなケースもありますが、少なくとも配置（左寄せ、右寄せ、中央寄せ）、書式（日付、時刻、金額、数量…）、フォント（書体、サイズ、色…）、折り返し設定くらいは設計情報として盛り込んでおきたいものです。特に、フォントの設定はVisualStudioの［メニュー］－［レポート］－［レポートの設定］－［スタイル設定］で設定した内容をレイアウトファイルとして保存しておくことができます。ガイダンスに設定情報を記載し、レイアウトファイルを統一テンプレートしてプロジェクトで共有するのも便利です。
以下はTextBoxコントロールのプロパティのうち、出力項目の定義によく使うプロパティを挙げたものです。必要に応じて、このほかのプロパティを指定するのもよいでしょう。
| プロパティ名 | 説明 |
| （Name） | コントロール名（物理名）を設定します。 |
| Alignment | 水平方向の配置を設定します。 |
| VirticalAlignment | 垂直方向の配置を設定します。 |
| DataField | バインドするデータソースのフィールド名を設定します。 |
| Font | 表示フォントを設定します。 |
| WordWrap | 自動的に折り返すかどうかを設定します。 |
| CanGrow | 出力するデータに合わせてコントロールの高さを拡大するかどうかを設定します。 |
| OutputFormat | 表示形式（書式）を設定します。 |
おわりに
今回は、帳票アプリケーション設計のうち前半部分の「帳票レイアウト設計」のポイントについて紹介しました。
次回は後半部分にあたる「データモデルの設計」と、その効果的な実装方法について紹介します。お楽しみに。
