130単位

MVCのモデルのあり方について考えた

開発

deeeki

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

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

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

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

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

WAF比較表

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

傾向

• 照会/登録はデータアクセスのクラスを介して行う
• データそのものの変数名がシンプルなものになっている
• 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単位

ツイートする

Permalink | コメント(0) | トラックバック(1)