どのようにこのタイプのデザインをクラスに分類しますか？

Question

私が見てきた以下のタイプのデザインは基本的に「薄い」クラスを持ち、あらゆるタイプの動作を除いています。セカンダリクラスは、挿入/更新/削除/取得に使用されます。

これは間違っていますか？それは反OOPですか？

User.cs 

public class User 
{ 

    public string Username { get; set; } 
    public string Password { get; set; } 
} 


Users.cs 


public class Users 
{ 
    public static User LoadUser(int userID) 
    { 
      DBProvider db = new DBProvider(); 
      return dp.LoadUser(userID); 

     } 

} 

Answer 1

私はそれをドメインオブジェクトまたはビジネスオブジェクトとして分類します。この種の設計のメリットの1つは、モデルがあらゆるビジネスロジックに依存しないようにし、異なる種類の環境で再利用できることです。

第2のクラスは、DAO（データアクセスオブジェクト）として分類することができます。

このパターンはまったく反発ではなく、広く使用されています。

Answer 2

あなたはdomain modelとdata-access objectを実装していると思います。いい考えだね。

Answer 3

user.csクラスはdomain transfer objectに貸していますが、Users.csクラスは実質的にdata-access objects内でビジネスルールを適用できる場所です。

あなたのクラスの命名規則と名前空間について考えてみてください。 users.csを見ると、基本的にユーザーのリストを扱うクラスになると仮定しています。

もう1つの方法は、作成した2つのクラスを組み合わせるActive Record Patternを調べることです。それは、これは、ますます一般的なパターンのようだとRob Conery's Storefront例Asp.Net MVCのアプリに影響を与える偉大に使用されているrepository patternかもしれないよう

User.cs 

public class User 
{ 
    public string Username { get; set; } 
    public string Password { get; set; } 

    public User(int userID) 
    { 
     //data connection 
     //get records 
     this.Username = datarecord["username"]; 
     this.Password = datarecord["password"]; 
    } 
} 

Answer 4

は、それは見えます。

基本的にデータアクセスコードをモデルから抽象化していますが、これは一般的には良いことです。私はモデルクラスへの少しの勇気を願っていますが。また、これまでの経験から、Userを呼び出すことは紛らわしく、UserRepositoryが勝手かもしれません。また、静的な（これは熱い議論ですが）削除を検討したいかもしれませんが、簡単に嘲笑します。さらに、リポジトリはインターフェイスを実装する必要がありますので、偽装して後で偽物に置き換えることができます。

Answer 5

実際にオブジェクト指向ではありません。なぜなら、そのオブジェクトは、データの集まりにすぎません。それはひどいことではありません。

Answer 6

最初のクラスは振る舞いのないデータを含んでいるため、反OOPです。anemic domain modelの典型的な例です。 OO言語で手続き型プログラミングを行う人にとっては典型的なことです。

しかし、DBアクセスがドメインモデル自体（アクティブレコードパターン）に入れられるのか、コード内で別のクラス（データアクセスオブジェクトパターン）に入るのかは、必ずしもドメインモデルと密接に結びついてはならない別個の技術的懸念事項です。