T . N E フレームワークの基本構造を理解する中垣健志 NAKAGAKI, Kenji 機能をひとつにまとめることです。ひです。AA f Nの特徴としては網羅的とつひとつは魅力的な機能でも、すである一方、概念的でもあり即座に朝晩の風の冷たさに、秋が感じられべてが協調して動いてこそ良いフレ実装に結びつけることが難しいといるようになってきました。秋用に新調ームワークになるのです。いくつかのうことがあります。これまでの連載したニットのネクタイをきりっと締め機能を組み合わせてはバラしていくでは、「概念的」な部分をいくつか取なおして、N君は仕事に取り掛かりま作業は、なんとなく野球やサッカーり上げて「実践的」な実装方法の説す。の監督業を思い出させます。1番から明を行なってきました。って複数のプロジェクトで生産性や書いてありました。クラスの役割を品質に寄与するためには、実践的な考慮した、一番良いクラス構成にす実装方法のうち普遍的なものを再利るにはどうしたらいいのでしょうか。用可能なプログラムとしてあらかじめ N君の今日の仕事は、「クラスの役割用意する必要があります。このよう分担についてじっくり考えること」なプログラムは、かつて「共通ライブになりそうです。ラリ」という形で提供されていました。 Technology Tools Visual Basic Visual C# Visual C++ SQL Server 4 5 現在ではオブジェクト指向や Webア Oracle Access ASP.NET フレームワークの作成 Other: プリケーションという最近の流れを受けて「フレームワーク」という形で提供するのが主流になっています。 p 3 Application Architecture for .NET Webアプリケーションそのものを（以下AAfN）は、Microsoftが提供す作るときもフレームワークを作ると 2005 December 161 A 2 r のときに読んだ「野球入門」にこう 1 A 開発になってしまいます。AAfNを使 n で構成するのが望ましい――小学生 Level o 装作業に関してはすべてゼロからの i じた役割をこなせるスペシャリスト t え方こそ再利用しているものの、実 a 並べるよりは、それぞれの打順に応 c ムワーク化する」というテーマで難し i しかしこのままではAAfNという考 l 9番まですべてホームランバッターを p 「前のプロジェクトの成果をフレー c h i t e はじめに t るWebアプリケーションの構築方法 c いのは、バラバラに作成した便利な u r e 第 8 回株式会社CSKシステムズ IT生産技術部 f o r Application Architecture for .NET の利用例 A p きも、行なわれる作業そのものに大きな違いはありませ色を決める重要なポイントです。そこで、以降で機能のん。すなわち、「要件定義→設計→実装→テスト」とい選別を行なう際の指針についてみていきます。うフェーズを踏んでシステムを完成させていきます。 p 指針1 「あれば便利な機能」ではなく「必ず使わなけれ l ばならない」機能であること i 要件定義よく、フレームワークとライブラリを混同してしまう c ことがあります。どちらも、あらかじめ用意されたプロ a 要件定義では、フレームワークに実現させたい要件をグラムを用いて実装時の手間を省くことができます。し t 定義していきます。しかし通常のWebアプリケーションかし両者には決定的な違いがあります。それは、ライブ i における要件定義に比べて、フレームワークの要件定義ラリは「あれば便利な機能」であるのに対して、フレー o には難しい点があります。それはフレームワークの場合、ムワークは「必ず使わなければならない機能」であるこ n 要件定義を行なうときにその内容を評価する「利用者」とです。別の観点から両者の違いを見てみると、ライブがいないということです。したがって、フレームワークラリは呼び出されるものであるのに対して、フレームワの設計者自身が利用者の役割も果たす必要があります。ークは呼び出すものである、といえます（図1）。 A まずは過去に作成したWebアプリケーション（ここでは ASP.NETを例に挙げて、考えてみましょう。 r Soarアプリケーション）から、他のプロジェクトでも使 ASP.NETでライブラリに相当するものとしては、ボ c えそうな機能を列挙することから始めると良いでしょタンやテキストボックスなどのコントロールが挙げられ h う。ます。Webページを作成するときには、必要となる任意 i ここでは例として、これまでの本連載の内容を踏まえ、 t あれば便利だと思われる機能を挙げてみましょう。のコントロールを使うことができますが、すべてのコントロールを必ず使わなければならないというわけではあ e りません。あらかじめ完成されているコントロールを実 c ・統一されたデータ操作・複雑なSQL文の自動生成装者が呼び出して画面上に配置していきます。これに対してフレームワークに相当するものとしては、 t ・データの排他制御コントロール Webフォームを呼び出す仕組みが挙げられます。Web u ・トランザクションの制御 r ・ビジネスロジックの「部品化」 e ・画面遷移のコントロール図1：ライブラリとフレームワークの違い処理の流れ・画面に配置されたコントロールの制御 f ・入力値の妥当性確認 o ・認証情報の管理あらかじめ用意されている部分ライブラリ利用者が作成する部分フレームワーク・統一された承認処理 r ・ログ出力インターフェイス・統一化された例外構造と例外補足処理 . ・etc. N E もちろんこれは一例であり、これらをすべてフレームワークで実現すべきかどうかはまだわかりません。どれ T だけの機能を持ち込めばよいかは、フレームワークの特 162 Windows Developer Magazine ライブラリでは、ひとつひとつが独立した部品がいくつも用意されている。利用者は必要なライブラリを自分で呼び出すフレームワークでは、あらかじめ処理の流れが決められた部品が用意されている（枠線内）。利用者が作った部品がフレームワークから呼び出される