私はEntity FrameworkとPOCOについて学んでいますが、私は多くの概念が好きですが、私はそれを得ていないと思います。ここでは例です:Entity FrameworkとPOCO
私は次のようなスキーマを持っている:
create table Customer
{
Id int,
Name varchar(32),
Value1 varchar(32),
Value2 varchar(32),
Value3 varchar(32)
...
Value50 varchar(32)
}
-- ColumnName will map to "Value1", "Value2", etc
create table ColumnMapping
{
ColumnName varchar(32),
DisplayName varchar(32)
}
このデータを表すオブジェクトは、次のようになります。
で、私は値1をマッピングしたいclass Customer
{
public Id { get; set; }
public Name { get; set;}
public Dictionary<string, string> CustomData { get; set; }
}
(DictionaryのKeyはColumnMappingテーブルによって決定されます)。
私はこれに最善のアプローチが何か不思議です。
私はPOCOであることを希望しますが、これを行うには、これらの列を辞書に変換できるように、Value1..Value50について知る必要があります。しかし、POCOが無知なままであるべきであることを考えると、私はそれが正しいアプローチであるかどうか疑問視しています。
一般的に、私はPOCOが本当に何であるかと悩んでいます - ビジネス層で使用されているオブジェクトか、POCOと "ビジネスオブジェクト"の間のマッピングが必要ですか? 「ビジネスオブジェクト」はビジネスレイヤーで使用されるべきものです。
このタイプのシナリオにどのように対処するかアドバイスをいただければ幸いです。
編集
私は私が尋ねるしようとしていた質問への回答を受け取っていないとして、私は先に行くと、私は(場合には、誰もがこの同様の問題を持っている)ことを決めたものを示します。 POCOは、それがどのように永続化するかを知る必要がないという点で無知であるが、全く無知ではない。つまり、何らかの方法でパーシスタンス層に結びつけなければなりません。
私の例では、ビジネス層にValue1、Value2、Value3などを知らせたくないのですが、誰かがそれらの値を辞書に変換するために知る必要があります。私は、その論理を置くための適切な場所はPOCOだと信じています.POCOはValue1、Value2、Value3などの列のプロパティを持つ必要があります。
おかげで、ORMの世界では エリック
典型的なアプローチです。私はあなたが別のスキーマを使うべきだと提案していると思います。そして、これは特定のアプリケーションではこれより優れているかもしれませんが、上記のスキーマを持つ必要があることをこの質問で仮定しましょう。私が言及したスキーマでは、私はPOCOオブジェクトがどのように見えるべきか、ビジネスレイヤに異なる(しかし同様の)オブジェクトを持つことが理にかなっているかどうか疑問に思っています。 – Eric