A p p Application Architecture for .NET の利用例 l i c a t プレゼンテーションレイヤーのフレームワーク実装 i 第１０回株式会社CSKシステムズ IT生産技術部中垣健志 o NAKAGAKI, Kenji n 今日はN君の会社の仕事始めです。 A はじめに r c 「新年明けましておめでとうございま h す！」ションで実現した機能をフレームワ休み中は地元に帰ってのんびりしてークに取り込んでいきましょう。今回いたN君ですが、心機一転して仕事には、プレゼンテーションレイヤーで提取り組んでいこうと思っています。さ供する機能を設計していきます。プレゼンテーションレイヤーが果た早いうちに、フレームワークを完成さす役割は、ユーザーとアプリケーショせる必要が出てきました。なぜならンとの対話を実現することです。ユーば、.NET Frameworkを使った大きザーからの問い合わせを受け付けてなプロジェクトが、また始まりそうだビジネスロジック以下の処理を呼びからです。そのプロジェクトにタイム出し、処理結果を再びユーザーへ返 Technology Tools リーにフレームワークを提供できれすということの繰り返しです。プレゼ Visual Basic ば、今後受注する他のプロジェクトにンテーションレイヤーは、内部的に Visual C# も、どんどんフレームワークを採用し以下の2つのコンポーネントにより実 Visual C++ てもらえそうです。現されます。 i て、いきなりですが、今年のなるべく t Level e c 1 2 3 4 5 t u r e SQL Server 去年は、Soarアプリケーションの成 f o r Oracle 果のうちの半分くらいをフレームワー ①ユーザープロセスコンポーネント Access ク化することができました。もうひとユーザーインターフェイスが提供す ASP.NET がんばりすれば、フレームワークとしる、複数のインターフェイスの処理順 Other: ての基本機能を全部提供できそうで序を管理するコンポーネント。たとえす。N君と一緒にがんばりましょう！ば、「本を検索する画面」「購入者の Visual Studio .NET 2003 . 情報を入力する画面」「確認画面」と N Samples E T この記事で取り上げたソースコードおよびサンプルプログラムは、 http://www.shoeisha.com/mag/windev/ からダウンロード可能です。フレームワークを設計する前回に引き続き、Soarアプリケー 144 Windows Developer Magazine いう3つの画面を経て書籍を購入する機能の場合、3つの画面（≒ユーザーインターフェイス）が正しい順序で遷移することを、ユーザープロセスが実ザーが同時にアクセスします。そのため、これらのユーユーザーに対して、目に見えるインターフェイスを提供ザーごとにひとつのインスタンスを用意しなければなりするコンポーネント。画面や帳票のデザインといった出ません（図1）。 Webアプリケーションにおけるインスタンスの数の関プロードによる入力要素を担当する。エンタープライズ係は、開発中にひとりでしかアプリケーションを動かしシステムを構成するコンポーネントのうち、もっともユていないと発見しづらいものです。Webアプリケーショーザーに近い場所に配置される。ンは常に複数のユーザーが利用することを前提にして、 f 力要素と、キーボードからの直接入力やファイルのアッ r . ②ユーザーインターフェイスコンポーネント E しているひとつのアプリケーションの中で、複数のユー N です。しかし、Webアプリケーションの場合には、稼動 o 現することになる。 T プレゼンテーションレイヤーのフレームワーク実装設計と実装を行なう必要があるのです。より具体的にいえば、画面間で受け渡される情報の管理、および画面の遷移そのものの管理を行ないます。「コンテキストクラス」を用意する方法があります。コンテキストとは一般的に「文脈」という意味で使われますが、オブジェクト指向でクラスを設計するときにンでは、複数のインターフェイスでユーザープロセスをは「特定の単位で常にひとつしか存在しないクラス」と共有する方法を採用しました。さらに共有場所として、いう意味合いで使われることが多いです。たとえば.NET hiddenタグ、ViewState、Cookie、セッションの4つに FrameworkにはSystem.Web.HttpContextというクラスついて検討し、その結果「セッション」を用いることをがあります。このクラスは、ユーザーからのHTTPによ・画面でユーザープロセスを取得する仕組みこのクラスからプロセスを取得するようにします（図2）。をSoarフレームワークとして提供することにします。図1：ユーザープロセスはアプリケーション単位でシングルトンではない方法を考えます。ユーザープロセスクラスは、機能の数ユーザープロセスクラスは、それぞれひとつのインスタンスだけ作成されるようにします。ここでデザインパタプロセス1 ユーザーBのセッションプロセス1 c ーンをご存知の方は「ひとつだけのインスタンス」と聞プロセス2 プロセス2 i いて、シングルトンパターンを使えるのではと考えるか l もしれませんが、ここでは誤りです。注1）本誌2005年9月号の本連載（ユーザーインターフェイスを実装する後編）を参照。 p シングルトンパターンは、アプリケーション単位でインスタンスがひとつであることを保障するための仕組み c i ユーザーAのセッション t だけアプリケーションで定義されます。そしてすべての Webアプリケーション a まず、セッションの中にユーザープロセスを保存する r かないユーザープロセスコンテキストクラスを用意して、 o ・セッションでユーザープロセスを共有する仕組み A ザープロセスの場合にはセッション単位で常にひとつし n るリクエスト単位で常にひとつしか存在しません。ユー各ユーザーごとのセッションでは同じプロセスのインスタンスはひとつしか存在しないひとつのWebアプリケーションとしてみるとプロセス1のインスタンスは複数存在している 2006 February 145 p 。そこで、 A 決めました［注1］ h i t 画面間で情報を受け渡すために Soarアプリケーショ r 合の常套策のひとつとして、ユーザー単位で作成される u ーインターフェイスの関連を調整する役割を持ちます。 t るためにはどうすればよいでしょうか？このような場 c ユーザープロセスコンポーネントでは、複数のユーザ e では、ユーザーのセッション単位でプロセスを管理す e ◆ユーザープロセスコンポーネント