Entity Framework и POCO - PullRequest
Новая
       2

Entity Framework и POCO

1 голос
/ 17 февраля 2012

Я изучаю 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) 
}

Объект, представляющий эти данные, выглядит следующим образом: 

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

То есть я 'Мне бы хотелось отобразить Value1 в Value50 в словарь (где ключ словаря определяется таблицей ColumnMapping).

Мне интересно, каков наилучший подход к этому.

Я бы хотел, чтобы Заказчик был POCO, но для этого ему необходимо знать о Value1..Value50, чтобы он мог преобразовать эти столбцы в словарь.Но учитывая, что POCO должен быть постоянно невежественным, я задаюсь вопросом, является ли это правильным подходом.

Я думаю, в общем, я борюсь с тем, что на самом деле является POCO - это тот объект, который используетсябизнес-уровень, или должно быть соответствие между POCO и «бизнес-объектом», и «бизнес-объект» - это то, что должно использоваться бизнес-уровнем.

Любые советы о том, как иметь дело сэтот тип сценария будет оценен по достоинству.

Редактировать

Поскольку я не получил ответа на вопрос, который пытался задать, я продолжу иукажите, что я решил (в случае, если у кого-то есть подобная проблема).Хотя POCO постоянно невежественен в том смысле, что ему не нужно знать о том, как он сохраняется, он не является полностью невежественным.То есть он должен быть каким-то образом привязан к постоянному слою.

В моем примере, хотя я не хочу, чтобы бизнес-уровень знал о Value1, Value2, Value3 и т. Д., Кто-то должен знать об этом, чтобы преобразовать эти значения в словарь.Я считаю, что правильное место для этой логики - это POCO, и поэтому я считаю, что POCO должен иметь свойства для столбцов Value1, Value2, Value3 и т. Д.

Спасибо, Эрик

1 Ответ

1 голос
/ 17 февраля 2012

В мире ORM это типичный подход 

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; }
}
...