9

私はこれがさまざまなコードベースであることを見て、これが一般的に眉をひそめているかどうかを知りたいと思いました。

例えば：

public class MyClass
{
   public int Id;

   public MyClass()
   {
      Id = new Database().GetIdFor(typeof(MyClass));
   }
}
4

7 に答える 7

11

まあ..私はしません。しかし、繰り返しになりますが、私のアプローチには通常、クラスが自身のデータを取得する責任を負わないことが含まれます。

于 2008-10-01T21:44:55.263 に答える
11

これが一般的に良い設計とは見なされない理由はいくつかありますが、そのうちのいくつかは、困難な単体テストやエラー処理の難しさを引き起こすなど、すでに言及されています。

そうしない主な理由は、オブジェクトとデータ アクセス レイヤーが非常に緊密に結合されているためです。これは、元の設計以外でそのオブジェクトを使用するには、大幅な手直しが必要になることを意味します。たとえば、そのクラスの新しいインスタンスを永続化するために、値を割り当てずにそのオブジェクトを使用する必要があるインスタンスに遭遇した場合はどうでしょうか? コンストラクターをオーバーロードしてから、他のすべてのロジックがこの新しいケースを処理するようにするか、継承してオーバーライドする必要があります。

オブジェクトとデータ アクセスが分離されている場合は、インスタンスを作成して、それをハイドレートしないことができます。または、同じエンティティを使用するが別の永続化レイヤーを使用する別のプロジェクトがある場合、オブジェクトは再利用可能です。

私は過去にプロジェクトで結合するより簡単な道をたどったと言っていました:)

于 2008-10-01T22:54:47.123 に答える
7

また、クラスにdbクラスのモック/スタブバージョンを使用させることができないため、クラスの単体テストを作成することも困難になります。ここを参照してください：http： //en.wikipedia.org/wiki/Dependency_injection

于 2008-10-01T21:49:26.560 に答える
7

DB 接続を参照する場合は、使い捨てパターンを使用できます。

public class MyClass : IDisposable
{
    private Database db;
    private int? _id;

    public MyClass()
    {
        db = new Database();
    }

    public int Id
    {
        get
        {
            if (_id == null) _id = db.GetIdFor(typeof(MyClass));
            return _id.Value;
        }
    }

    public void Dispose()
    {
        db.Close();
    }
}

使用法：

using (var x = new MyClass()) 
{
    /* ... */

} //closes DB by calling IDisposable.Dispose() when going out of "using" scope
于 2008-10-01T21:51:41.797 に答える
4

ええ、あなたはそれを行うことができますが、それは最良の設計ではなく、コンストラクターでのエラー処理は他の場所ほど整然としていません。

于 2008-10-01T21:49:01.600 に答える
1

このアプローチで私が考えることができる唯一の問題は、DB初期化からのエラーがコンストラクターからの例外として伝播されることです。

于 2008-10-01T21:44:51.597 に答える
-2

本物ではなくモックオブジェクト/スタブを使用したいのはなぜですか? 自動車メーカーが衝突試験に板紙モデルを使用することに同意しますか?

于 2008-12-03T10:47:28.483 に答える