0

私はCassandraを重度の非正規化で使用しているため、オブジェクトのすべてのタイプに変更が必要なテーブルの独自のリストがあるため、オブジェクトを削除/追加/更新/などするためにある種のユニバーサルクラスを使用することはできません。

たとえば、削除するUserには、1 つだけでなく 3 つのテーブルに触れる必要があります。削除するItemには、7 つのテーブルなどに触れる必要があります。これは、オブジェクトの種類によってロジックがまったく異なることを意味します。

シナリオ 1

ユーザー クラスには、必要なフィールド (ID、名前など) と、ユーザーの検索、ユーザーの削除などの静的関数のみが含まれています。

<?php

class User {
    private $id;
    private $name;
    // Magic getters and setters removed to save space here

    public static function delete($id) {
        // find user by id
        // delete that user
    }
}

シナリオ 2

ユーザークラスにはすべてがあります-フィールド（ID、名前など）と、その特定のユーザーを削除/編集/作成/などする関数も含まれます

<?php

class User {
    private $id;
    private $name;
    // Magic getters and setters removed to save space here

    public function delete() {
        // find user by $this->id
        // delete that user
    }
}

どちらのシナリオが優れていますか?これを行うには、さらに優れた方法が他にあるでしょうか?

4

1 に答える 1

0

私は＃2に投票します。

重要なことは、1 つを選択し、その理由を明確にして、それに固執することです。これらのアプローチを混在させたり、特定のアプローチを選択した理由が明確でない場合、事態は非常に混乱します。

シナリオ 2 は、何を削除するかが明確であり、常に に関連しているため$thisです。

また、シナリオ 2 では、この検証をコンストラクターにオフロードするか$id、オブジェクトまたはデータベース行を削除する前に設定されているかどうかを簡単に確認できるため、delete メソッドの検証はあまり必要ありません。

ただし、シナリオ 1$idでは、実際に何かを削除していることを確認するために、削除しようとする前に存在することを確認する必要があります。削除された行数を返すこともできます。これは、それ自体も検証になる可能性があります。しかし、将来的には、この検証は、何が削除されているかを確認するだけではなく、より複雑になる可能性があります。

構築またはload()関数に検証の多くを処理させる方がよいでしょう。

于 2013-07-30T20:18:23.723 に答える