日々の破片

_ NET Architect Seminar 2004

出社したら昨日（追記：20日の出来事なのでここでの昨日というのは19日のこと）の夕方に届いていたお誘いメールを発見。席が余ったのかなぁ、とか考えながらも、ありがたくプリントアウトして、午後、ドームホテルへ。

Doom Hotelだとちょっとおどろおどろしいが、そんな気が利いたホテルではなかった。ちなみに、zooはツォーだったりゾオだったりするわけだからDoomでドオムってのもありだろう。

とか、どうでもいいことを考えながら地下へ降りてNさんに挨拶。復調したのなら良いのだが。今日は午前と午後があってとか言うので、まさか重複コードをリファクタリングしたりはしてないですよね？ と訊くと、そりゃないだろうとか。

司会のマイクを取ろうして、演壇はあっちと教えられると、照れてるんだかなんだか、妙な足取りで右へ進む。ああいう時には、さりげなくムーンウォークとかすると良いだろう。（追記：以降、ほとんど同時通訳を利用。通訳が追いついていない部分では英語のほうも参照しているが相当怪しい）

で、いきなり「午後の部では」とか言い出すので、このオッサンちゃんとわかってるのかいな？ と思ったが、そつなく始まる。2時間（3時間かな？）分のパワポだが90分だから途中を素っ飛ばすと言明。多分、MSとしては、ページコントローラを素っ飛ばされるのは嬉しくないんじゃないかな。それはそれとして、あまりにそつが無いので退屈する。PoEAAのプロモーションに来たのかなぁ。途中、うまく通訳で伝わるかなとか言いながらギャグを飛ばしたようだが印象には残っていない。そこで「やっぱり通訳付きじゃ通じないか」とかブツブツ言ったのには受けたが。

ロウデータゲイトウェイのところで、スタティックメソッドによるファインダメソッドが必要となり、それによって、モック（ファウラーの用語ではスタブ）の使用ができなくなるから、ファクトリを別途使用することを提案（なのかな）。っていうか、そのまんまCMPエンティティビーンとホームインターフェイスですがな。

データマッパーは実装がすごく大変だから、おれたちソートワークスみたいに優れたデータマッパーの実装を持ってなければやめときな、というようなことを言い出す。リレーションがあると確かに単純には実装できそうにもないかな、とちょっと実装戦略を考えているうちに分散パターンへ突入。

コモンシナリオを見せる。これはカスです、と言明。いくらアメリカ人でも、顧客にはそうは言えないけどねと注。全く正しい。

コーバーピープルって何かと思ったが、CORBAピープルのことか。痛い目にあったのかなぁ。そりゃ合うだろう。分散オブジェクトっておもしろいんだけど、インプロセスとは違うからな。

透過、透過って、おまいら速度を意識したことは無いんでつか、と怒ってみせる。まったく正しい。しかし速度よりも、障害だよ、真の問題は。（と、速度をクリアしていたもので実践投入――DCOMだけど――したことのある僕は呟くのであった）

リモートファサード。粗粒度インターフェイスの利用。だからDTO。

でも、インプロセスなら、こんなもんいらんもんね。

そうかな？ それこそ透過APIで済むのではないか？

アドレスデータをレコードセットと考える。これはDTOだ。ただし、コントローラ（アドレスファサード）のインナークラスとして（コントローラへのバックポインタを持つと）考える。

DTOではあるが、insertのようなメソッドについては、内部でコントローラへthis（これはDTOだ）をデリゲートすることで済ませることが可能だ。

ロウデータゲイトウェイには、ファインダクラスを設けることにするのがベストプラクティスなのだから、それをファサードとして利用可能では無いか、と考える。

で、質疑応答。

ドメインモデルのインスタンス生成コスト問題。そんなものよりDBを気にしろ。うーん、そうなのか？ そうなのかも。というか、その通りなのだが、まあ、考えどころではある。

現実問題としては、正しい。無意味な文字列生成のように短期間に爆発的に生成されるわけではないので（特に更新処理）ほとんどのインスタンスはトランザクション境界と同程度の寿命を持つ。レコードをグルグル読みまくるようなものにドメインモデルを利用してはいけないというのは当然で、ファストレーンがそのためにあるわけだし。

SOA。なんか、最初の解釈ってのは、箱モノが外部にサービス提供するのは良いアイディアだと言い出す。それはOfficeアプリケーションが外部にサービスを提供するのは良いアイディアだのOLE1、2、フィニッシュみたいだ。同じことだが、サービスの粒度が異なるってことかいな。

非同期重要。正しい。

でも、Webサービスは重たいから、エンドとエンドを自分で決定できるのなら、（ミドルウェア）ネイティブなプロトコル、つまりリモーティングやRMIを使え、そのほうが効率的だ。と言い出す。

それは違う。速度はドメインでのDB処理の見直しによって考えるべきだ（と早速、流用）。やはりプロトコルがどこまで透明かが重要となる（インターフェイス透過のことでは無い）。リモーティングやRMIを利用するのであれば、独自にUDP上にアプリケーションプロトコルを作成すべきだ。と僕は考えるが、まあ、いいか。一般論としては間違いではないし、障害の発生頻度は環境にも依存するからだ。それでも、僕は（ほとんどの局面で）HTTPを使うけどね。

追記：WRさんのレポートを読んでいて思い出したが、XML Webサービスを使ったらXMLシリアライゼーションにバカな時間を食ったと言っていたのを思い出した。そりゃそうだ。まだ、XMLシリアライゼーションはH/Wに追いついていない分野だと考えたほうが良い。バイナリシリアライゼーションのPOST（るいもさんの案）か、SAX（または独自シリアライザー／デシリアライザー）とXSLT（言語としてのXSLではなく、独自に要素のマッピングをする変形ツール）を利用（まあ、ソートワークスのデータマッパじゃないが僕はインフラがあるし）しなければならないのはHTTPを利用する上での現時点での良識（オブジェクトがでかい場合については。少なければSOAPで十分）。

テスティングフレームワークについて。UIドライバって作るの大変だよね、とか。まったくだ。そこでプレゼンテーションレイヤはとにかく薄く作ってテスティングフレームワークが適用可能なドメインとは分離すべきだ、と最初の3層の話につなげたのかな、ちょっと記憶が曖昧。

あと、IoCの質問とか。角谷さんの翻訳について触れる。.NETでも役に立つんじゃない、と軽く流す。

もし役に立つなら、次期VS.NETじゃなくて（.NET Frameworkだろうな）に組み込まれるだろうし、そうじゃなければしょぼしょぼだろう。役に立つかどうかは.NET開発者にどれだけTDDが受け入れられるかどうかだな。

案）

System.Testingネームスペース

TestCaseクラス

System.Containerネームスペース

MicroContainerクラス（ナノピコよりでかいところがMSだ）

というわけで、なかなかおもしろかった。

で、終了後神保町へ行って、書泉グランデ。あ、洋書が無くなっている。で帰る。

追記：僕の考えと、ファウラーが喋ったことの分離度を低く抑えて書いている（俗流意識の流れってやつでね）ので、dotNETArchitectSemi2004と照合したほうが良い。

追記：なんか、結構違うな。UIドライバと両エンドを自分で管理可能な場合。前者はこっちの記憶が曖昧だからあっちが正しいかも。後者はこっちが正しいと思うが確証はない。

追記：DBのモック（スタブ）が重要なのは、テストの速度。例）実際にDBと接続するユニットテストは40分（かな？）、モックを使うのは数10秒。ソートワークスでの話。時間については誇張があるような気もするが、正しい。

_ XML Webサービス問題点（追加）

さっそくWRさんのコメントを参照してリンクをたどる。わ、大容量文書だ。それで「きちんと読んでません」になるんですね。僕もきちんとはまだ読んでません（へたすると読まないかも）（追記：これは読む価値があるから、やはりちゃんと読む）。

2種類のシナリオがあって、

1.インターネットシナリオ（みんなが望むXML Webサービス（B2Bとか））

2.イントラネットシナリオ

1.の場合は、スキーマによる検証が必須となると思います。そのためには、ネームスペースなどフルオプションで付ける必要があるでしょう。が、2.の場合は検証済み（受け入れテストをしてるはずです）システム間の通信となるため、厳密な検証は不要です（バグは別。でもバグはXMLを使うかどうかとは関係ない）。

検証をしなくても良いとなれば、デシリアライゼーションは相当、速度が向上します。また、現在、イントラネットの通信は（除く障害）速度についてはH/W進化の恩恵を非常に受けている分野です。一昨年の100Kバイトデータは、今年の1Mバイトデータ並かそれより大きい（可能性がある）。

とか、書き始めたが、ちょっと割り込みが入ったので多分、ここまで。