2 つのデータ ストレージにまたがって保存されているビジネス オブジェクトがあります。オブジェクトの一部は Azure Table Storage に格納され、残りの部分は Azure SQL に格納されます。基本的に、SQL 部分はクエリで使用され、Table Storage は多くのスペースを必要とするプロパティに使用されます。
ほとんどの場合、オブジェクトの SQL 部分のみが (SQL クエリで) 使用されます。Table Storage プロパティは、誰かがそのオブジェクトを明示的に要求した場合にのみ必要です。私が達成しようとしているのは、ビジネス オブジェクトの背後に 2 つのデータ ソースがあるという事実を隠し、ストレージ テーブルのプロパティを遅延ロードし (SQL クエリを実行するときには必要ないため)、コードをテスト可能にする設計です。
私の現在の設計には、作業単位によって作成された POCO がいくつかあります。Table Storage 用と SQL 用の 2 つの POCO を作成したくないので、次の設計について考えていました。
//Make the properties virtual
public class Customer
{
public virtual string Name {get;set;} //Stored in SQL
public virtual string Age {get;set;} //Stored in SQL
public virtual string Details {get;set;} // This prop is stored in Table Storage
}
//Create a derived internal POCO that can notify when a property is asked
internal class CustomerWithMultipleStorage
{
public event EventHandler OnDetailsGet;
public override string Details
{
get { if (OnDetailsGet!=null) OnDetailsGet( ... ); /* rest of the code */ }
set { /* code */ }
}
}
すべてのデータ レイヤー コードは動作しますがCustomerWithMultipleStorage
、DL の外部にあるすべての「外部」コードは使用Customer
され、イベントは公開されません。これで、作業単位が を返すとCustomer
、SQL プロパティのみが読み込まれ、Get イベントがサブスクライブされます。Customer を使用しているユーザーが残りのプロパティを必要とする場合、イベントがトリガーされ、Table Storage プロパティが読み込まれます。
このデザインについてどう思いますか?それは正しいアプローチですか?これを行うより良い方法を知っていますか?