流行のアーキテクチャの話。

何となく、漫然とした意識がホァホァとしたけれども、
きっちりまとまらなかったり。

結局の所、アウトプットする事が重要って話に、脳内会議で決まりました。
ヲチが無い上に、まとまりもありません。(防御線)
でも、文章だけはやたら長いです。

前提として、Type2MVCモデルを全体としては念頭に置く事とします。

アプリケーションがレイヤー化されている事によって、
そのままでは、回避困難な状況に陥った時、
トリックを使う範囲を論理ベースで限定出来るのは、
人間がミスをする以上、必要な事です。

Viewレイヤーの話。

画面を作るのは、誰か？と言う話が、一番重要です。
デザインを生業とする人の成果物は、全く触らずに済むなら、それが一番です。
HTMLにScriptletを加筆したり、HTMLをTaglibで置き換えていく作業は、
簡単な様で、ミスを誘発したり、生産性が安定しなかったりすると、経験上、感じます。

僕は、標準って学習曲線を緩やかにする為の手段としては、
それなりに妥当だとは思うけど、それ程重要だとは思いません。
標準よりも、デファクトに興味があったりなかったり。
只、HttpSessionにベッタリなテクノロジには、パフォーマンス上の危険を感じます。

DTOとEntityが、別。と言うのは、僕にとって、それ以外の選択肢はありえません。
ひがさんの言が全てだと思います。
但し、全てのコードを人間がせっせと記述するのかと言われると、
それはそれで、話が別です。

HTTPの基本に余り逆らわない事を条件に、
DTOは、Pageに作るのが良いと思われます。
バランス感覚の問題ですが、入力/出力の組み合わせが単純になり易い為、
理解が早い…、と経験則的に感じます。
作成されるクラスの量を見積もるのも、一部の例外的状況を除けば、非常に簡単です。

でも、Flash,Flex,AjaxみたいにRIAだとどーかなぁ…と言う問題点は残ります。
RIAについては、キチンと分析する時間を、とらないといけないと思いつつ、
後回しになっています。

Contollerレイヤーの話。

WebControllerとApplicationControllerと言う表現が大好きです。
多分、初出は、PofEAA。
WebController(Strutsで言う所のActionクラス)には、
画面dependな処理しか書きたくありません。
もっと言うと、テストが面倒だから、ここではコードを書きたく無いなぁ…と妄想します。
コードを書きたく無いという事は、勿論XMLなんぞ話にもなりません。
id:masataka_kさんのアイディア位尖ってるのが、個人的には好みです。
一方で、ポトリペタリと、リッチなエディタで、何とか出来るものなら、
それはそれで、イイかなぁ…とも思います。

僕は、ApplicationContorollerが、トランザクション境界になると考えます。

ビジネスロジックと言う何だかアレなモノを切り出すのは、
生産性とテスタビリティと魔法の為です。
画面にdependする処理は、Seleniumイイ！とか言いながら、
自動テストをほぼ諦め気味ですが、そうでない部分は存在する筈です。

WebControllerは、本質的に、画面が完成しなければテスト出来ないと考えますが、
ApplicationControllerは、そうではなく、画面とは独立してテスト出来うると考えます。
つまり、WebControllerより画面よりな部分を製造する事と、
ApplicationControllerよりRDBよりな部分を製造する事は、平行化出来うると考えます。

極端な話、最初単純だからと言って、
RDBにストアされるモデルを画面に直接持ってきてしまうと、
生産性を維持できなくなる局面があると思います。
これは、判断するにあたって、システムを開発する目的にかなり依存すると思いますが…。

Modelレイヤーの話。

JPAには、それ程興味を持てません。
SQLを隠蔽する事に価値を見出せず、
データストアとしてRDBが使われない世界を、僕にはイメージ出来ない事と、
Java特有のテクノロジである為です。
結局S2DAOサイコーってな訳です。SQLゴリゴリ書きましょうとな。

リッチなドメインモデリングは、遊びとしては非常に楽しいと思いますが、
仕事では使いたくありません。
理由は、キチンとやりきれる人が少な過ぎると感じている為です。
僕が、構造化とSQLをキッチリやっても
尚、解決できない程、難しいシステムの開発に携わった事が無い為かもしれません。
但し、システム全体から、オブジェクト指向を完全に排除するのかと言われると、
そんな気もありません。
只、オブジェクト指向な部分と、非オブジェクト指向な部分を、
どの様にして合理的に、切り分ける事が妥当なのかを明言する事も又、
僕に能力が足りない為、出来ません。

結局の所。

アーキテクチャは、プロジェクトに参加する８割の人間の想像を超えない事が重要だと考えます。
理解のプロセスを正確に見積もる事は出来ず、
理解しているかどうかを妥当な範囲で判断する事も非常に難しいと思います。
極まった状況になれば、なる程に。
又、何よりコミュニケーションコストが、
プロジェクトにおいて最も重大なコストであると感じる為です。

但し、存在を全く気付かせない領域に、
高度なテクノロジを「仕込む」事は必要だと考えます。
つまり、実装技術としてのAOPはアリですが、
設計技術としてのアスペクト指向は、(？)です。

まぁ、結局、何が言いたいのか、よく分らないエントリになってしまいました。