日々の破片

_ 妙な言葉は納得は早くても忘却も早い。

WRさんのとこにごにょごにょ書いている最中に、ある言葉がそれを意味していると気付いたのだが、その「ある言葉」を思い出せない。

あそこで、僕がイメージしている疎結合システムを意味する用語ってなんだっけなぁ？（誰もお前のイメージなんかわかるかってというツッコミは置いておいて）。

エコシステムか、サプライチェーンだと思うんだが、サプライチェーンだと対象領域が限定された使用例しか思いつかないし、エコシステムというと余りに怪しげだし、何か用語があったはずなんだが…(検索中)…やっぱりエコシステムかなぁ。

……どうもそうらしい。それにしてもこんな使用例もあるが、やはり怪しい言葉だな。

_ VB.NET必勝パターン（続）―IoCコンテナは.NETでも有効か？

有効。理由は以下のとおり。

VB.NET必勝パターンを誰でも知ってるStrutsに対応させると、ここでのDataSetはActionFormに相当する。IDEのプロパティエディタで設定できるという意味ではDynaActionForm以上の利便性を持つ。かつ、スキーマ定義はドラッグアンドドロップ可能なビジュアルエディターで編集できるから楽チン至極。

Validationイベントハンドラは自分で記述しなければならないとは言え、VB.NETのインテリセンス付き構文エディタ（であってるか？ プリティプリントするだけでも構文エディタと呼ぶような記憶があるからその意味じゃあってるはずだし、コンパイルエラーも記述時点で判明するから―すげぇな良く考えてみると―あってるだろう）でちゃかちゃか記述できるのだからこれも良い。

と考えてみると、VB.NETのWindows Formアプリケーションは、Enterキーによる「実行」処理のイベントハンドラの記述をActionと見立てて、MVCのCとVの混在だということがわかる。ただしVのうちTextBoxだのCheckBoxだのは、自動的に処理がされるわけだし、DataSetと束縛させておけばLabelなどへの自動表示もサポートされているわけだから、非常に手数は少なくて済む。

ここで、DataSetをそのままデータベースとのインターフェイスデータとして利用すれば、それはテーブルモジュールパターンとなり、DataSetはそのままモデルとなる。

しかし、DataSetをユーザー入力の単なる入れ物（まさにActionForm)として扱う場合には、Actionに相当する実行ボタンハンドラから、モデルへの委譲を記述することになる。この場合、モデルは普通にクラスを作成していくのでも良い（ドメインモデルパターン）。ドメインモデルの呼び出しがWebサービスの呼び出しとなるのであれば、その場合、Windows Formはプレゼンテーション層に相当するのだが、Webサービスから見れば、入力のバリデーションは完了しているため、イントラネットシナリオに限定すればドメイン層のうち、ユーザーファサード（という呼び方があるかは知らないが、意味的にはユーザーインプットに対するファイアウォールということになる）までを担当していることになる。Webサービスではなく、Remotingを利用するのであれば、ドメイン層のうちファサードまでを担当していると見なすことも可能。（インターネットシナリオでのRemotingはあり得ず、Webサービスであれば入力の検証は必須――XSS脆弱性はともかくとして）。

ここで重要なのは、ティアの分割が2層のクライアント―サーバであっても――これは、DataSetを直接テーブルモジュールとして操作する場合、およびモデルに相当するクラスから直接DataAdapterなどを利用する場合のいずれであっても、モデルは、Windows Formとは分離したクラスとして実現できることである。

このように構成されたアプリケーションは16ビットWindows時代のベタなクライアント―サーバとは同一視できない。たまたま、物理的な配置が2層になっているというだけで、論理的にもオブジェクトモデルにおいても、3層以上の構成となっているからだ。

なぜならば、ローカルに配備されたモデル相当のクラスは、実際にはリモートに配備することも可能だからだ。

さて、ここで1998年に戻ってみる。Windows DNAだ。同じ構成は実際にはVB6でも可能であった。モデルをCOMのコンポーネントとしてアプリケーションからは分離可能であったからだ。ここで、COMのコンポーネントをリモートのMTS内に配備すれば、同様の多層構造となる。

ここでの問題は、やはり、DCOMの信頼性に尽きる。初期設定であり、かつ変更が不可能なPING（6分だったっけな？）も当然、問題だ。DCOMに比較すれば、OLEDB（またはODBC）のほうが遥かに安定した通信を提供する。したがって、現実的なアプリケーションは仮にCOMのコンポーネントとしてモデルを実装してもクライアント上に配備することになる。この結果だけを考えれば、あえてCOMのコンポーネントとするよりも直接アプリケーション上にデータベースへのアクセスコードを記述する2層クライアント―サーバシステムとしてしまうというのも現実的な解だ。

ただし、VB6の時代では、COMのコンポーネントが重量コンポーネントだったという事実を割引く必要がある。レジストリへの登録が必要であり、OLE2のようなDLLを必要とするからだ（1度ロードした後はvtblバインディングが行われるため実行上のペナルティは型システムの制限以外は無い）。

.NETにおいては、すべてが.NET Framework内での実行となるため、COMのコンポーネントのように重量が……というような考慮は基本的には不要である。（追記：もちろんRemotingの信頼性はDCOMの実績を加味すべきだし、Webサービスが重量級なのは事実。したがって物理配置は2層が望ましいと判断したーしなくても良い―と仮定した上で、）したがって、論理構造（およびオブジェクトモデル）としては、多層で実装したとしても実行上のペナルティは課せられない。である以上、仮に物理配置においては2層クライアント―サーバであっても多層構造によって実装すべきであることは自明である。

シナリオ：

・社内のPCからのアクセス（モデルはPCへ配備し、データベースへはPCからアクセス）

・出先のノートパソコンからのアクセス（モデルはWebサービスとしてWebサーバへ配備し、データベースへはWebサーバからアクセス）

の両者に同一Windows Formアプリケーションが利用できるということは、それだけで十分なメリットである。もし、1アプリケーション内にデータベースアクセスを記述してしまえば、後者のケースには対応できない。

また、このシナリオを有効にするには、モデルに対するビジネスデリゲートが必須となるのも当然である。

ここで、ビジネスデリゲートの実態は、サービスロケータ＋ファサードだという点を考えてみるとIoCコンテナの有効性がわかる。サービスロケータが有効なシナリオではIoCコンテナもまた有効だからだ。

したがって、IoCコンテナの出番は、第1にはWindows Formアプリケーションのためということになる。