0

私のアプリでは、ID を文字列として格納する DB を使用しています。DB には、ドキュメント/行ごとに別のプロパティ (Etag) も格納されていました。そのため、ドメイン エンティティをこの基本クラスから派生させました。

public class EntityBase : NotifyPropertyChangedBase
{
    public string Id { get; set; }
    public Guid ETag { get; set; }
}

現在、アプリケーションに別のデータ レイヤーを追加していますが、古いレイヤーを削除したくありません。実行時の決定に基づいて、特定のデータ層を切り替えて使用できると便利です。問題は、新しい DB に Id を int として格納したいということです。そして、ETag はその新しい DB では不要な概念です。

私はこの変化をどう管理するか悩んでいます。EntityBase.Id を int に変更すると、古いデータ レイヤーはコンパイルされません。古いデータ レイヤーを使用している場合は特定の EntityBase を使用し、新しいデータ レイヤーを使用している場合は別の EntityBase を使用したいと考えています。それはただ一つの考えです。たぶん、より良いアプローチがありますか？これを機能させる方法について何か提案はありますか?

ところで、永続化層の問題は、ドメイン層オブジェクト (ID が文字列または int など) までは機能しないはずだと思います。しかし、それでは遅すぎます。これが私が置かれている状況です。どうすればよいか、誰かが良いアドバイスをしてくれることを願っています。

Id2 を EntityBase に追加することを考えていました:

public class EntityBase : NotifyPropertyChangedBase
{
    public string Id { get; set; }
    public int Id2 { get; set; }  // New property for new DB only
    public Guid ETag { get; set; }
}

次に、新しい DAL マッピングで、テーブルの Id 列を Id ではなく Id2 にマップします。しかし、私のビジネス ロジックは Id のみを参照するため、これは機能しません。まだ考え中...行き詰まるかもしれません...

ハックとして、EntityBase を元の形式のままにしておくことができます。次に、新しい DAL で ORM を実行すると、テーブルの ID を文字列に変換するだけで済みます。

4

1 に答える 1

0

次に、もう 1 つのレイヤーを追加することをお勧めします。たとえば、次のような新しいクラスを作成するには:

public abstract class CommonEntityBase<T> : NotifyPropertyChangedBase{
    public T Id {get;set;} 
}

次に、このクラスから古い EntityBase を派生させます。

public class EntityBase : CommonEntityBase<string>{

    //this property is present only in this old implementation
    public Guid ETag { get; set; }
}

これで、新しいレイヤーを作成し、そのための基本クラスも使用できます。

public class FancyEntityBase : CommonEntityBase<int>{
    //No ETag concept here - ad new properties, methods, etc.
}

ただし、主キーを整数に変更する必要があるかどうかは疑問です。これにより、ORM の使用時にパフォーマンスの問題が発生する可能性があります。

于 2012-05-26T04:01:46.340 に答える