LogicとControllerとDaoと

開発

次のバージョン(何の?)では、Page, Dxo, Entity構成で、ロジックはEntityに書くことになります。Daoがなくなるのがポイント。

さらに次のバージョンでは、PageとEntityだけになり、PageはモデルとしてEntityを持つ用になり、今のようにPageに画面と対応した項目をもつことがなくなります。

http://d.hatena.ne.jp/szk-takanori/20070304#c1173054357

ここで言ってるEntityは、おそらくrailsのActiveRecordみたいなDao+DtoのことでModelのことではないのだろう（本当のModelはDB上にあるわけだし）。

今、頭の中にあることをとりあえず吐き出してみる（意味不明なことでもとりあえず書いてみることに意義があると信じてみるテスト）。

ViewはJSPなりJSFなりMayaaなり明白なので議論の余地はないし、Modelは前述の通りデータベース上にあるわけだから、その間はすべてMVCで言うところのControllerであるということだ。問題はControllerの中身をどう切り分けるかという話になる。

まずControllerの入出力を考えると、View<->Contorllerの入出力は何らかのActionとその結果であるし、Controller<->Modelの入出力はデータのCRUDに他ならない。

Actionの単位をメソッドにする（PageクラスやRailsのControllerはこれ）かクラス（Strutsはこれ）にするかは議論の余地はあるけれど、基本的にはどうでもいい話ではある（しかしながら、開発においては本質的でないことが重要であったりするので、本当はどうでもいい話ではないが今は関係ない。ちなみに私は前者の方が楽なので好き）。なお、Actionがトランザクション境界であるという点に異論はない。

問題は、Actionとデータを接合するいわゆるロジックをどこに書くべきかである。現在のGoyaのモデルだと、Action/Page, Service/Logic, Daoに書かれている。ただ、これには使い分けがあって、Action/Pageには入力とService/Logicを結びつけるグルーコードのみを書き、Service/Logicに具体的なロジックを書き、Daoはデータのアクセスに限定したものだけを書くことになっているのだと思う。

おそらく本当の問題なのは、その切り分けが実際には難しいという点にある。まぁ、とはいえAction/Pageに書く内容とService/Logic/Daoに書く内容の区別はある程度明確化できるとは思う。なぜならAction/Pageの内容は処理の概要がわかるようなものになるからだ。区別が難しいのはどちらかと言えばService/Logic/Daoの方。一見、データアクセスとロジックは明確に区別できるじゃないかと思うかもしれないが、検索ひとつとってもビジネスロジックと言えるし、UNIONやCASE分や計算式を駆使したSQL文をデータアクセスだと言ってしまうのは無理がある。Stored Procedureの呼び出しに至っては何を況や。

そのように考えていくとひが氏の言う「PageとEntityだけになり」という意味がなんとなくわかった気がする。ただ、思うにそれはEntityではなくFeatureとでも呼ぶべきものなのではないだろうか（いや、Featureと呼ぶと処理が重視されているように聞こえるな。データも含むわけだからComponentとかの方がしっくりくる？）。