PHP MVCのBaseModel、良いか悪い？

Question

私は自分のMVCフレームワークをPHPで学習しています。正しいコントローラ/アクションなどを呼び出すためのルータ/ディスパッチャクラスを持つことは本当に難しいことではありませんでした。

しかし、今私はモデルを使用する部分にいます。実際には、モデルレイヤーです。しかし、私を混乱させる何かがあります。

他のMVCフレームワークの多くは 'BaseModel'を持っています。私はこれが実際に悪い習慣であることを読んだことがあります。なぜなら、 "モデル"は別のクラスと見なされるべきではないからです。しかし、「マッパー」パターンや「リポジトリ」パターンなどのものを含むことができる実際の「レイヤー」として。

しかし、正直言って、私はそれに利点はありません。私にとっては、「BaseModel」クラスが同じ結果を出して最速の方法だと思われます。

私は単にような何か行うことができます。

class User extends BaseModel 
{ 
    // the GetUserBy* could easily be something that's handled by the 
    // BaseModel class, like in the Repo pattern. 

    public function getUserByName ($name) 
    { 
     // no error handling of any kind, just for simplicity 
     return $this->db->exec("SELECT * FROM users WHERE name='".$name."'"); 
    } 

    // $data = array 
    public function saveUser ($data) 
    { 
     // Make sure no extra fields are added to the array 
     $user = array ('name' => $data['name'], 
         'address' => $data['address']); 

     $this->db->autoSave ($user); 
    } 
} 

をしかし、私は、リポジトリのパターンのために行くだろうならば、私は次のものを作成する必要があります。 リポジトリ エンティティ DAO

エンティティはに凝集体を持っています他のリポジトリ。だから基本的に私は手動でオブジェクトに私のデータベース全体のスキームを書いています...

最後に、何が違いですか？それ以外の場合は、単にBaseModelクラスを使用するだけで、多くの時間を節約できる可能性があります。

しかし、なぜそれでもまだ悪いと思われますか？私が今やっていることよりも、レポパターンが私のアプリケーションを切り離すわけではありません。私にとって、上記のパターンは非常に過大評価されているようです。おそらく共有状態を持つアプリケーションでのみ動作します。オブジェクトをリポジトリにローカルに保存し、後でコミットします。

私は誰も本当にこれに答えることはできないと考える理由...だ

しかし、私はまだ私が行かせるまともな答えを見ることを望んでいる：「えーえ...私は何を考えていた.... "しかし、そうでなければ、BaseModelが悪いことではないと私は確信しています。ほとんどのブロガーは単なる羊の束です:-)

Answer 1

レポパターンは、私は が今やっているより多くのそして私のアプリケーションを切り離していないことを

あなたのアプリケーションが緊密に（、実際には、あなたのマッパーとして動作している）SQLデータベースのコンポーネントに結合され、 。しかし、これにもかかわらず、あなたのデザインはActive RecordのアプローチよりもはるかにRepositoryに似ています（これはあなたが参照するこれらのブロガーの多くが悩んでいる可能性が高いです）。

アクティブレコードはデータだけでなく、データベースへのアクセスだけでなく、カプセル化：

$user = new User(); 
$user->setUsername('jane'); 
$user->setEmail('jane@foo.bar'); 
$user->save(); 

それはレコードオブジェクトを永続化層（関心事の分離）を知らないことが持っているよりよいです。あなたの "ベース"は、ユーザーデータの配列を返すことによってそのことを行い、それらの配列が変更されたときには、それらを保存するためにユーザー "ベース"に渡す必要があります。あなたはあなたの命名を次のように変更することができます：

class UserRepo extends BaseRepo 
{ 
    // user-specific repo code... 
} 

$userRepo = $this->getRepo('User'); 
$user = $userRepo->getUserByName('jane'); 
$user['email'] = 'jane@new.email'; 
$userRepo->save($user); 

ベースレポを持つことは何も問題ありません。

Answer 2

Modelクラスは、それらを実装することなく。 Userモデルについては、これらすべての機能を持つインターフェイスGettingUsersを簡単に作成し、Userモデルで実装することができます。

Answer 3

あなたのモデルのほとんどは、それらが従うべき統一されたインターフェイスを持たないため、私は基本モデルを全く使用しません。必要に応じて、さまざまな種類のモデル（基本的なオブジェクト指向プログラミング）の基本クラスを作成できます。

全体的に、私はモデルがコントローラーと配線し、1つまたは複数のビューで配線する「緩い」コンポーネントであると考えています。それらはすべて、異なるものを行うため、統一されたインタフェースを持つことはできません。永続ストアと話したり、永続性を持たないものや、他のモデルで構成するものがあります。

Answer 4

PHPフレームワークから優れたMVCプラクティスを習得しようとしているなら、それは間違っています。 PHPのベストフレームワークでさえ、設計上の間違いや欠陥が詰まっています。

"BaseModel"は通常、何らかのORMを実装しているフレームワークです。そして最も人気のあるパターンはActiveRecordです。シンプルなテーブルでは、他の人とは関係なく（基本的にはゲッター/セッターに栄誉を与えられます）、それはいいです。しかし、より複雑な構造やクエリを扱う際には、まず解消し始めます。通常広範囲になるtechnical debt。

このアプローチが問題を引き起こす理由は、この場合の「モデル」が責任を負う可能性があるということです。ビジネスロジックはストレージに緊密に束縛されており、ストレージはロジックに溶接されています。アプリケーションが成長すると、そのような「モデル」はハッキングを蓄積します。

いいえ、「ブロガーの束」は羊ではありません。彼らはアプリケーションアーキテクチャとオブジェクト指向プログラミングに関する本を読んだだけです。あなたはこのテーマに関する本を最後に読んだのはいつですか？