2010-04-03

deeeki モデルとかエンティティとかDAOとかDTOとかの自分の中での定義付けをはっきりさせときたい ( 2010-04-03 16:48:21 )

既存Webアプリのコードを踏襲しながら新規開発、なんてことをしています。そこで立ち止まったのが、MVC アーキテクチャのモデルについて。モデルという言葉の定義が難しいですが、RDBMSを利用する場合テーブル毎に対応するもので、ロジックを主に記述するものという捉え方でいます。そのモデルですが、ざっくりと「データアクセスロジック」と「データそのもの」に分けられると思います。

既存コードでは、データアクセスとデータそのものが一つのクラス/オブジェクトでまかなわれていました。つまり、自身でテーブルのカラムに対応したプロパティを持ち、自身にupdateやらdeleteやらのメソッドを持つというものです。

この構造になんとなく違和感を持ったまま開発をしていました。というのは、データ(レコード)1件に対してならつじつまが合いますが、複数のデータを扱おうとすると若干無理が生じてくると思うからです。複数件照会のメソッドで配列を返すか、あるオブジェクトの中にそれ自身が複数並ぶ配列型プロパティを持たせるとかしないといけないんじゃないかと思います。

そこで、他のフレームワークを調べてみました。

WAF比較表

触れたことのあるもののみです(※Ethnaは経験1日の知識)。

言語	フレームワーク	データアクセス	データアクセスの変数名	データそのもの	データそのものの変数名
PHP	CakePHP	AppModel	$Controller->Xxx	連想配列	$xxx
PHP	Ethna	AppManager	$xxx_manager	AppObject	$xxx
Java	SAStruts	Service*1	xxxService	Entity	xxx

傾向

照会/登録はデータアクセスのクラスを介して行う
データそのものの変数名がシンプルなものになっている
EthnaはAppObjectで登録などができるっぽい

調べた結果

調べている中で、とても納得のいく説明を見つけたので引用してみます。

ビジネスロジックをエンティティとサービスのどちらに定義するのかは、とても重要な問題です。データアクセスロジックは、サービスに定義したほうが良いでしょう。なぜかというと、検索系のメソッドは、エンティティを取得するためのメソッドなので、エンティティ自身には定義できません。エンティティのstaticメソッドとして定義すれば、できないこともありませんが、 staticメソッドだと、テスト用にオーバーライドすることができないので、やめておいたほうが良いでしょう。

また、更新系のメソッドは、エンティティに持たせることもできますが、そのためには、エンティティが更新系のメソッドが定義されている特定のクラスを継承する必要があり、最近のPOJO指向とかみ合いません。データアクセスロジックは、エンティティではなく、サービスに定義するほうが良いのです。
Super Agile Struts - Feature Reference

そんなわけで、データアクセスとデータそのものは分けたほうがいいという考えに至りました。

きめた方針

データアクセスのクラス命名規則をXxxModelとする
データアクセスのオブジェクト(変数)命名規則を$XxxModelとする
データそのもののクラス命名規則をXxxとする
データそのもののオブジェクト(変数)命名規則を$xxxとする

これでやってみようと思います(PHPです)。

参考リンク

モデルというよりMVCについての記事ですが。

Life is beautiful: Ruby on Railsの「えせMVC」の弊害 
http://satoshi.blogs.com/life/2009/10/rails_mvc.html

 Web アプリの MVC 設計まとめ - もやし日記 
http://d.hatena.ne.jp/p4life/20091014/1255532618

  CakePHPを使ったMVC設計のベストプラクティス - Sooey 
http://old-journal.sooey.com/2008/03/26/717/

【関連記事】
自己流MVC開発体験記 - 130単位