CODEWITHSUNDEEP
entity-framework-4.1poco
Eric
Eric

Reputation: 2047

Entity Framework and POCO

I am learning about the Entity Framework and POCOs and while I like a lot of the concepts, I think I am not quite getting it. Here's an example:

I have a schema like the following:

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) 
}

The object which represents this data looks like:

class Customer
{
    public Id { get; set; }
    public Name { get; set;}
    public Dictionary<string, string> CustomData { get; set; }
}

That is, I'd like to map the Value1 to Value50 to a Dictionary (where the Key of the dictionary is determined by the ColumnMapping table).

I am wondering what the best approach to this.

I'd like the Customer to be a POCO, but in order to do that, it would need to know about Value1..Value50 so that it would be able to convert those columns into a dictionary. But given that a POCO should be persistent ignorant, I am questioning if that is the right approach.

I guess, in general, I am struggling with what the POCO really is - is it the object which is used by the business layer, or does there need to be a mapping between the POCO and a "business object" and the "business object" is what should be used by the business layer.

Any advice on how to deal with this type of scenario will be appreciated.

Edit

As I didn't receive an answer to the question I was trying to ask, I'll go ahead and indicate what I decided (in case anyone has this similar issue). While the POCO is persistent ignorant in that it doesn't need to know about how it gets persisted, it's not entirely persistent ignorant. That is, it has to be tied to the persistence layer in some manner.

In my example, while I don't want the business layer to know about Value1, Value2, Value3, etc, someone needs to know about it in order to convert those values to a dictionary. I believe that the right place to put that logic is the POCO and hence, I believe the POCO should have properties for the Value1, Value2, Value3, etc, columns.

Thanks, Eric

Upvotes: 1

Views: 241

Answers (1)

Ray
Ray

Reputation: 4108

In ORM world, this is typical approach

class Customer
{
   public int Id { get; set; }
   public string Name {get; set; }
   public virtual ICollection<CustomDatum> CustomData { get; set; }
}

class CustomDatum
{
   public int Id { get; set; }   // PK
   public string ColomnName { get; set; }
   public string DisplayName { get; set; }
}

Upvotes: 1

Related Questions