6

学習目的で、PHPで独自のMVCフレームワークを作成しています。適切なコントローラー/アクションなどを呼び出すためのルーター/ディスパッチャークラスを持つことはそれほど難しくありませんでした。

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

他の多くの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はまったく悪いことではなく、ほとんどのブロガーは羊の群れにすぎないと確信しています:-)

4

4 に答える 4

1

リポジトリパターンがアプリケーションを切り離しているわけではありません。

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

アクティブレコードは、データだけでなく、データベースアクセスもカプセル化します。

$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);

ベースリポジトリがあることには何の問題もありません。

于 2012-04-23T17:24:23.327 に答える
1

PHPフレームワークから優れたMVCプラクティスを学ぼうとしているのであれば、それは間違っています。PHPの最高のフレームワークでさえ、設計上の間違いや欠陥がたくさんあります。

「BaseModel」を持つフレームワークは通常、ある種のORMを実装しています。そして、ここで最も人気のあるパターンはActiveRecordです。これは、他の人との関係がない単純なテーブルに適しています（基本的に-栄光のゲッター/セッター）。しかし、より複雑な構造やクエリを処理すると、機能が低下し始めます。通常、多額の技術的負債を引き起こします。

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

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

于 2012-04-24T21:29:14.173 に答える
0

クラスは抽象である必要があり、Modelメソッドを実装せずにメソッドを定義するだけです。モデルに関しては、これらすべての機能を備えUserたインターフェースを簡単に作成し、それをモデルに実装できます。GettingUsersUser

于 2012-04-23T15:33:24.027 に答える
0

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

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

于 2012-04-23T16:46:06.883 に答える