2

私は PHP を使い始めたばかりなので、ひどく間違ったことをしている場合は、私のコードを許してください。
「保険」オブジェクトに対して私が持っているこのメソッドを見てみましょう。これは、保険を言ったすべてのクライアントを返します。

public function getBeneficiarios() {
        $petitionsVariables = array(
            PeticionDeCoberturaColumns::COBERTURA_ID => $this->getId()
        );
        $petitions = (new PeticionDeCoberturaDAO())->getByValues($petitionesVariables);
        $clientes = array();
        foreach ($petitions as $petition) {
            $clientes[] = $petition->getClient();
        }
        return $clientes;
    }

上記のコードは、特定の DAO に結合されているため、明らかにあまりテストできません。適切にテストするには、DAO をモックして、モックを注入する必要があります。

それを行う依存性注入の方法は

public function getBeneficiarios($dao) {
        $petitionsVariables = array(
            PeticionDeCoberturaColumns::COBERTURA_ID => $this->getId()
        );
        $petitions = $dao->getByValues($petitionesVariables);
        $clientes = array();
        foreach ($petitions as $petition) {
            $clientes[] = $petition->getClient();
        }
        return $clientes;
    }

保険オブジェクト コンストラクターに DAO を挿入することもできますが、単一のメソッドで使用する必要があるという理由だけで、関連のない DAO を渡すという考えは好きではありません。

getBeneficiarios メソッドを使用するたびに、最初に DAO を作成する必要がありますが、非常に直感に反するように思えます。将来のコーダーは、それについて気にする必要はありません。

快適に使用できるコードと快適にテストできるコードの両方を維持するにはどうすればよいでしょうか?

4

1 に答える 1

0

あなたの問題はクラスのテスト可能性ではなく、アプリケーションの設計にあるようです。

真の DDD では、クラスは DAO に依存したり、DAO の存在を認識したりしてはなりません。あなたはそれを持続性無知と呼ぶことができます。Insurance オブジェクトが認識する必要があるのは、関係者 (顧客、保険会社) と、法律用語などのその他のビジネス概念だけです。

カプセル化に関する最も重要なことは、クラスの消費者がそれをうまく使用するために、他のクラスの内部動作について知る必要がないということです。保険を静的 DAO オブジェクトに依存させると、カプセル化が壊れます。これは、静的 DAO がどこかに存在しなければ例外が発生することを消費者が知る必要があるためです。

DAO は実装の詳細です。ドメイン オブジェクトは、ドメイン オブジェクトに依存したり認識したりしてはなりません。ドメイン オブジェクトに依存する必要があります。IoC は、関心の分離やカプセル化など、より基本的なことを保証する手段です。設計上、これらに違反している場合、IoC の量でそれを修正することはできません。出発点として、DDD の観点から設計を検討します。次の質問を見てください: DDD でのデータ アクセス レイヤーの設計

これが役立つかどうか教えてください。

于 2012-10-15T12:15:21.323 に答える