0
をテストします。 Courseエンティティ自体は、ユーザーがアクセスできるかどうかを決定するロジックを提供します。これはうまくいきますが、コントローラーをテストする方法という問題につながります。コントローラのための具体的なPOCOのビジネスロジックをモックすることは、私は、次のコントローラを持っているとしましょう
私のコントローラテストでは、course.userCanAccess（）が特定の結果を返すようにする方法が必要です。私のエンティティPOCOにはインターフェイスがないので、私はそれらを嘲笑することはできません（これが間違っている場合は私を修正してください）。
私は、userHasAccess（）が私が望むものを返すように設定されたテスト用の完全なCouseオブジェクトを作成することができますが、メソッドは「水和」されたコースの特定の関連エンティティに依存し、ワイヤーアップする雑用。
私はテストに慣れていないので、続行方法が不明です。
コースはPOCOではないと私は同意しますが、ビジネスロジックは常にサービスレイヤに属している必要があります。ドメイン層でサービスパターンを使用することも、エンティティにメソッドを直接配置することもできます。エンティティにメソッドを追加すると、たとえClrオブジェクトがPlain Oldよりも多くなっても、ドメインモデルが充実します。 – danludwig
フェアポイント。私は、定義上、POCOにビジネスロジックを含めることはできないと言っていました。あなたは好きな場所にビジネスロジックを置くことは許されていますが、それがPOCOになったらPOCOでなくなります。 :-) –
私は、POCOという用語は、それがCLR以外の技術やフレームワークに結びついていない単なるクラスであることを意味すると思います。ドメイン層クラスはしばしばPOCOであり、ViewModelは通常はPOCOです。 ViewModelsにビジネスロジック（合意）はないはずですが、DDDに従っている場合は、ドメインレイヤークラスにビジネスロジックが必要です。 – drogon