web-dev-qa-db-ja.com

.NETプログラミングとPOCOクラス

変更が必要なアプリケーションについて熟考しているときに、今夜は考えていました。エンティティフレームワークエンティティはPOCO（プレーンな古いCLRオブジェクト）であり、ASP.NET MVCで使用されるモデルも通常POCOです。これは基本的にプロパティだけを意味し、メソッドは意味しません。

現在OOプログラミングでは、通常、オブジェクトのプロパティとメソッドを含む機能をカプセル化できます。これにより、ポリモーフィズムが発生します。使用されるPOCOクラスの増加に伴い、デザインパターン過去に私のリポジトリに独自のCRUD操作があったはずなのに、今ではリポジトリに置いています。

これは単なるOOの進化ですが、CRUD操作がオブジェクトから削除され、それらを分離できるようになっていますか、それともCRUD操作が過去のオブジェクトレベルにあるべきではなかったので、私は間違っている？一体、多分両方とも完全に合法であり、常にそうであった。

design-patternsobject-oriented.net
9
James

ワイアットが言ったように、POCOとPOJOは決して方法を意味しません。それは非POCOと非POJOが何であるかを知らないことに由来すると思います。

ORMテクノロジーの最初のバージョンは、エンティティがフレームワーク自体から基本クラスを継承する必要があるという単純な理由から、POCOおよびPOJOではありませんでした。 Java、Entity Beansの場合。EntityFrameworkの場合、最初のバージョンではPOCOは不可能であり、各エンティティはEntity基本クラスを継承する必要がありました。

この要件により、データモデルが永続化テクノロジに依存するようになり、多くのことが困難または不可能になりました。モデルのユニットテストのようなものは、実際には不可能であることが判明したBean /エンティティフレームワークをモックする必要があります。また、異なる永続化テクノロジでモデルを使用したり、モバイル環境のように異なるコンテキストでモデルを使用したりすることもできません。

したがって、POCOがメソッドの非存在についてであるというあなたの仮定は間違っています。 POCOは、モデルを永続化テクノロジから分離して使用できるようにすることです。

あなたが話していることはおそらく Anemic Domain Model vs適切なドメインモデルに近いでしょう。

9
Euphoric

POCOはメソッドがないことを決して意味しません。ただし、ほとんどの例では、主にプロパティを処理し、メソッドを無視するMVC自動バインディング機能の多くを使用しています。

モデルオブジェクトに永続性を埋め込むと、懸念事項の分離に違反し、データベースを立ち上げずにオブジェクトの単体テストなどを行うことが非常に難しくなります。これはモデルオブジェクトの関数ではなく、リポジトリなどの別のクラスの場合の関数です。

4
Wyatt Barnett

それぞれ独自のメリットがある2つの異なるアプローチ。

https://stackoverflow.com/questions/1519669/data-access-layer-or-having-object-with-crud-methods

1
Norman Noble

最近、このようなものに Extension Methods を使用しています。

POCOには、オブジェクト自体に対してのみ意味のあるロジックが含まれています。ビジネスロジックまたは協調オブジェクトロジックは、BL拡張機能に入ります。データアクセスは、データアクセスレイヤーまたはデータアクセス拡張のいずれかに入ることができます。

_namespace MyApp
{
    public class MyClass
    {
        public string id;
        public string name;
        public int quantity;
        public decimal price;
    }   
}

namespace MyAppBL
{
    public static class MyClassBL
    {
        public static decimal PriceInCart(this MyClass myObject)
        {
            return myObject.quantity > 10 ? myObject.price * 0.9m : myObject.price;
        }
    }
}

namespace MyAppDA
{
    public static class MyClassDA
    {
        public static void Create()
        {
            …
        }

        public static void Read(string myObject)
        {
            …
        }

        public static void Update(this MyClass myObject)
        {
            …
        }

        public static void Delete(this MyClass myObject)
        {
            …
        }
    }
}
_

これにより、クラスをデータに集中させたまま、非常にいいmyObject.PriceInCart()とmyObject.Save()が得られます。もちろん、静的メソッドの場合、MyAppDA.Create()の代わりにMyApp.Create()が必要です。

0
Jeffery Thomas