速度はドメインでのDB処理の見直しによって考えるべきだ(と早速、流用)。プロトコルがどこまで透明かが重要となる(インターフェイス透過のことでは無い)。リモーティングやRMIを利用するのであれば、独自にUDP上にアプリケーションプロトコルを作成すべきだ。僕は考えるが、まあ、いいか。一般論としては間違いではないし、障害の発生頻度は環境にも依存するからだ。それでも、僕は(ほとんどの局面で)HTTPを使うけどね。Webサービスを使ったらXMLシリアライゼーションにバカな時間を食ったと言っていたのを思い出した。XMLシリアライゼーションはH/Wに追いついていない分野だと考えたほうが良い。バイナリシリアライゼーションのPOST(るいもさんの案)か、SAX(または独自シリアライザー/デシリアライザー)とXSLT(言語としてのXSLではなく、独自に要素のマッピングをする変形ツール)を利用(まあ、ソートワークスのデータマッパじゃないが僕はインフラがあるし)しなければならないのはHTTPを利用する上での現時点での良識(オブジェクトがでかい場合については。少なければSOAPで十分)。テスティングフレームワークについて。UIドライバって作るの大変だよね、とか。そこでプレゼンテーションレイヤはとにかく薄く作ってテスティングフレームワークが適用可能なドメインとは分離すべきだ、と最初の3層の話につなげたのかな、ちょっと記憶が曖昧。あと、IoCの質問とか。角谷さんの翻訳について触れる。.NETでも役に立つんじゃない、と軽く流す。Frameworkだろうな)に組み込まれるだろうし、そうじゃなければしょぼしょぼだろう。役に立つかどうかは.NET開発者にどれだけTDDが受け入れられるかどうかだな。案)System.TestingネームスペースTestCaseクラスSystem.ContainerネームスペースMicroContainerクラス(ナノピコよりでかいところがMSだ)というわけで、なかなかおもしろかった。終了後神保町へ行って、書泉グランデ。あ、洋書が無くなっている。追記:僕の考えと、ファウラーが喋ったことの分離度を低く抑えて書いている(俗流意識の流れってやつでね)ので、dotNETArchitectSemi2004と照合したほうが良い。追記:なんか、結構違うな。UIドライバと両エンドを自分で管理可能な場合。前者はこっちの記憶が曖昧だからあっちが正しいかも。後者はこっちが正しいと思うが確証はない。追記:DBのモック(スタブ)が重要なのは、テストの速度。例)実際にDBと接続するユニットテストは40分(かな?)、モックを使うのは数10秒。ソートワークスでの話。時間については誇張があるような気もするが、正しい。Webサービス問題点(追加)さっそくWRさんのコメントを参照してリンクをたどる。それで「きちんと読んでません」になるんですね。僕もきちんとはまだ読んでません(へたすると読まないかも)(追記:これは読む価値があるから、やはりちゃんと読む)。Webサービス(B2Bとか))2.イントラネットシナリオ1.の場合は、スキーマによる検証が必須となると思います。そのためには、ネームスペースなどフルオプションで付ける必要があるでしょう。2.の場合は検証済み(受け入れテストをしてるはずです)システム間の通信となるため、厳密な検証は不要です(バグは別。バグはXMLを使うかどうかとは関係ない)。検証をしなくても良いとなれば、デシリアライゼーションは相当、速度が向上します。現在、イントラネットの通信は(除く障害)速度についてはH/W進化の恩恵を非常に受けている分野です。一昨年の100Kバイトデータは、今年の1Mバイトデータ並かそれより大きい(可能性がある)。書き始めたが、ちょっと割り込みが入ったので多分、ここまで。10:42)RMIを使うなというのはおかしいので、artonさんが正しいと思います。Webサービスの問題点回避策として、以下のアイディアもあるようです。<br>http://java.sun.com/developer/technicalArticles/WebServices/fastWS/<br>ITU系のバイナリエンコード標準ASN.1を使うというものです。枯れた技術で、ツール類がすでにあるのが強みですが、大体価格が高い・・・。テレコム系なのでしょうがないかな。14:03)補足させてください。枯れた技術、ツール類云々はASN.1にかかります。12:34)ああ、なにかヒトコトいいたいかもかも。14:05)お願い、言って。