ここでさらに明確にすると、私が行うことです。
GraemeFによって提起された懸念に沿ったままで、あなたが望むことをすることはもろく、せいぜい壊れやすいです。
このため、一般的な方法は、設計時のデータサポートを実行時のデータサポートとはまったく異なるアプローチとして扱うことです。非常に簡単に言えば、設計時環境とこのDBの間に作成している結合は悪い考えです。
視覚化のための設計時データを単純に提供するために、ランタイムクラスとして共通のインターフェイスに準拠するモッククラスを使用することを好みます。これにより、正しいタイプであり、ランタイムオブジェクトと同じコントラクトに準拠していることを確認できるデータを表示する方法が得られます。ただし、これはまったく異なるクラスであり、設計時のサポートに使用されます（また、多くの場合、単体テストに使用されます）。
たとえば、名、名前、電子メールなどの個人の詳細を表示する必要があるランタイムクラスがある場合：
public class Person()
{
public String FirstName { get; set;}
public String LastName {get; set;}
public Email EmailAddress {get; set;}
}
実行時にDBからこのオブジェクトにデータを入力していましたが、設計時の視覚化も提供する必要があります。準拠するコントラクトを定義するIPersonインターフェイスを導入します。つまり、プロパティゲッターが存在することを強制します。
public interface IPerson()
{
String FirstName { get; }
String LastName { get; }
Email EmailAddress { get; }
}
次に、ランタイムのPersonクラスを更新して、インターフェイスを実装します。
public class Person() : IPerson
{
public String FirstName { get; set;}
public String LastName {get; set;}
public Email EmailAddress {get; set;}
}
次に、同じインターフェイスを実装し、設計時に使用するための適切な値を提供するモッククラスを作成します
public MockPerson() : IPerson
{
public String FirstName { get { return "John"; } }
public String LastName { get { return "Smith"; } }
public Email EmailAddress { get { return new Email("John@smith.com"); } }
}
次に、設計時にMockPersonオブジェクトを提供し、実行時に実際のPersonオブジェクトを提供するメカニズムを実装します。このようなものまたはこれ。これにより、ランタイム環境と設計時環境の間に強い依存関係がなく、設計時データのサポートが提供されます。
このパターンははるかに柔軟性があり、アプリケーション全体で一貫した設計時のデータサポートを提供できます。