PEAAにある.NET特有のアーキテクチャパターン

　仕事納めの今日、仕事の手も空いたので、「エンタープライズ アプリケーションアーキテクチャパターン」(マーチン・ファウラー著、通称「PEAA」)を一通り読み通した。
　すごく面白い！

　業界のアーキテクトやモデラーが、以前から注目していた本。
　PEAAは、業務系システムの設計パターンのうち、ORマッピング、トランザクション、WebUIなどを詳しく解説している。
＃余談だが、Amazonの感想文のうち、プロモデラーさんと奥村さんの感想がまさに的確。

　僕の場合、「AAfN(Aplication Architecture for .NET)を理解したいなら、PEAAを読むべき」と同僚から薦められたきっかけもあった。

　長年Javaで開発してきたので、J2EE特有のアーキテクチャ（ドメインモデル、データ変換オブジェクト、ページコントローラ）は自然に理解できた。純粋なオブジェクト指向開発者なら、これらのアーキテクチャは無意識でも使っている。

　特に目を引いたのは、.NET特有のアーキテクチャを説明している所。
　第1部では、ドメインモデルとテーブルモジュールの比較は目から鱗が出た。
　ORマッピングは、JavaとADO.NETで発想が全く違う。DataSetは、確かにテーブルオブジェクトそのものゆえ、DOAに近いと言っていい。DataSetは使いにくいのかと思ったら、むしろ、DataGridにDataSet丸ごと渡せるので、プログラムはすごくすっきり書ける。
　VBでは、DataSetやDataGridのAPIがないから、データ検索の結果一覧をFormへ表示するだけのロジックがすごく面倒。
　でも、DataGridもやはり機能が足りないので、FlexGridのようなサードパーティのモジュールを使う時も多い。
　
　Javaにはテーブルモジュールと言う発想はなく、ドメインモデルという発想。
　J2EEでオブジェクト指向をフルに使った開発では、RDBを意識することなく、POJOで処理を考えるのが普通。だから、コストがかかるEJBを使わない場合、DAOを自作することになる。そして結局、ORマッピングがボトルネックになり、Hibernate、TorqueなどのオープンソースのORマッピング・フレームワークが乱立している状況にある。
　
　また、EJBにはトランザクション管理だけでなく、分散オブジェクトの一面も持つのがいつも開発のボトルネックになる。
　だから、データ変換オブジェクトを使って、ドメインへの問い合わせ内容を一括して直列化するのが普通のやり方。いわゆるDTOパターンだが、Javaの場合自作するケースが多いから手間がかかる。

　では、.NETの場合どうするのか、と疑問に思っていたが、Webサービスを使うのが自然に設計に出てくる。「Webサービスとは単にリモート用途のインターフェイスにすぎない」という一節は、まさにその通り、と思わず相槌を打った。。
　VisualStudio.NETならば、Webサービスはウィザードで簡単に作れるし、クライアントは公開されたWebMethod属性のメソッドを単なるAPIとして利用するだけでいい。
　
　他にもなるほどと考えさせられる所はあるが、.NETのアーキテクチャは、純粋なオブジェクトのモデルを志向するJavaと違い、APIが多少複雑になろうとも使いやすさを優先しているという感想を持った。
　丸半日しか読んでいないのに、腑に落ちて理解できた所や重要そうな所に付箋を貼り付けたら、20本以上貼り付けてしまった。。

　Javaに限らず、.NET開発者にもお勧めの本です。