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

9

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

現在、OOプログラミングでは、通常、オブジェクトにその機能とメソッドを含む機能をカプセル化できます。これにより、ポリモーフィズムが発生します。使用されるPOCOクラスの台頭により、汎用リポジトリーなどの設計パターンがより一般的になっています。以前はオブジェクトに独自のCRUD操作があったはずでしたが、現在はリポジトリにあります。

これはオブジェクトからの進化であり、オブジェクトからCRUD操作を削除してそれらを分離できるようにしたのですか、それとも過去にCRUD操作がオブジェクトレベルにあるはずがなく、私が間違っていたのでしょうか？一体、おそらく両方とも完全に合法であり、常にそうでした。それは私が考えさせられた観察に過ぎないので、私は他の意見を求めるだろうと考えました。

design-patterns object-oriented .net

— ジェームズ
ソース

9

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

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

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

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

あなたが話しているのは、おそらく貧血ドメインモデルと適切なドメインモデルに近いでしょう。

— 陶酔
ソース

その通りです。それは、Anemic Domain Modelがその記事を読んでいるように見えます。

— James

4

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

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

— ワイアットバーネット
ソース

え？pocoは完全に私の経験ではメソッドを意味しません-それ以外の場合、それはエンティティ、モデル、またはビューモデルです。

— Telastyn 2013

2

前回チェックしたとき、Plain Old C-Sharp Objectはメソッドを持つことができました。この用語は、型付きデータセットのようなものがあるか、そうでなければモデルオブジェクトをPOCOではなく特定のクラスから継承する必要があった悪しき時代に起こりました。

— Wyatt Barnett

関心事の分離は、メソッドがインターフェースを受け入れるようにすることで、オブジェクトのメソッドを維持しながら実現できます。そのインターフェースは、オブジェクトのCRUD操作を処理できるタイプを指定します。

— ジェームズ

1

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

/programming/1519669/data-access-layer-or-having-object-with-crud-methods

— ノーマンノーブル
ソース

0

最近、このようなものに拡張メソッドを使用しています。

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()。

— ジェフリー・トーマス
ソース