-1

これが一般化されたシナリオです。「タスク」と「タスク イベント」があります。それぞれのデータベーステーブルを作成しました。データベースからのレコードのフェッチを処理するモデルも作成しました。

「タスク イベント」には、いくつかのタイプがあります。作成済み、承認済み、コメント、クローズ済みです。

$task = new Task($task_id);現在、データベースからタスクを取得し、$task_events = new Tasks_Events($task_id);そのタスクのイベントを取得するような簡単なことをしています。次に、イテレータを実装したので、これを行うことができforeach($task_events as $e) { ... }、すべてうまく機能しています。

ただし、いくつかのイベント タイプには特殊なハンドラーが必要であることがわかりました。たとえば、Tasks_Events を拡張する Tasks_Events_Comments を作成し、Comment イベント タイプに対して追加の処理を行います。私が今気づいたことは、イベントのコレクションを収集するとき、それらが子の型であることが本当に必要であるため、イベントでメソッドが呼び出されると、子の型から適切なオーバーライドが呼び出されるということです。

簡単な例を次に示します。

class Model {
    public function __construct($search = null) {
        // Hypothetical example, basically query the DB and populate data.
        if (!is_null($search)) { $this->search($search); }
    }
    protected function onAfterUpdate() { }
}

class Tasks_Events extends Model {
    protected function onAfterUpdate() { /* Task Event Specific */ }
}

class Tasks_Events_Comments extends Tasks_Events {
    protected function onAfterUpdate() { /* Task Event Comment Specific */ }
}

次に、仮定の使用例:

class Controller {
    public function updateEvent($task_id, $event_id, $params) {
        $task = new Tasks($task_id);
        $task_event = new Tasks_Events($event_id);

        // Some Analysis of Params
        $task_event->status = $new_status;
        $task_event->save();
    }
}

だから、ここが鍵です。このようにすると、Tasks_Events onAfterUpdate() が呼び出されます...

私の質問は、モデル、パラダイム、哲学、アプローチとは何かということです。タスク イベントのコレクションがあり、基本クラスの参照を使用している場合でも、そのイベントに対してアクションを実行するために使用できるものは何ですか?子クラス関数が呼び出されます。

Tasks_Eventsがデータベースにクエリを実行し、タイプを決定し、「切り替え」を実行して、返される適切なタイプを作成するようなことをすることです$e = new Tasks_Events(3); $e->status = 4; $e->save();$e = Tasks_Events::Get($id);

それが気に入らないもう 1 つの理由は、モデルを$tasks = new Tasks(array('user_id' => 5, 'status' => Tasks::STATUS_OPEN));構築して適切なデータベース クエリを構築し、開いているユーザー 5 のすべてのタスクを入力するなどのクールなことを行うためです。それから私はできるforeach($tasks as $t) { echo $t->subject; }など.だから、私はこの種のシステムを維持できるようにしたいと思っています....しかし、サブタイプの継承を利用したい場合、できるかどうかはわかりません。

Factory パターンが必要になるのではないかと心配していますが、何かが足りないだけかもしれません。

PS より良いタイトルが思いついたら、自由に変更してください。

4

1 に答える 1

0

ありがとう@Sam Dufel、あなたのコメントは私に深く考えさせ、私のデザインの大きな欠陥に気づきました.

あなたは $task->getEvents() の良い提案をしましたが、私の質問の重要な (欠陥?) ポイントを忘れていました。これも悩んだ原因かも…

基本的に、イテレータとゲッター/セッターを実装した方法がおそらく問題の原因です。生レコードの配列を反復処理するためです。

次に、イテレータの 2 番目の位置にいるとしましょう。$item->status を呼び出すと、チェックする __get($name) が呼び出されます$this->records[$this->position][$name]!! それで、ご覧のとおり、私は自分自身を隅に描きました。ファクトリ パターンを使用しても、Tasks_Events (モデル) argh 内にイテレータを実装した方法が原因で、これはうまく機能しません。

ご迷惑をおかけして申し訳ありません。考えてくれてありがとう。

更新:私がしたことは、「DAO」と「モデル」を組み合わせて「モデル コレクション」を有効にしたことです。私はそれらを分離するつもりです。DAO->find() はモデル コレクション (反復可能) を返し、DAO->findOne() はモデルを返します。3 つすべてを 1 つにまとめることは便利でしたが、私のニーズが拡大するにつれ、あまり拡張性がありませんでした。

于 2012-05-13T23:34:31.593 に答える