.NET Entity Framework

Question

Является ли плохой практикой использование созданных объектов из Entity Framework в качестве бизнес-объектов? Что лучше написать вторичную оболочку вокруг объектов Entity Framework, которую я бы потом передавал между слоями?

Например, написать мой собственный POCO Person, который принимает один из моих сгенерированных объектов Entity Framework EFPerson для инициализации объекта POCO Person?

Answer 1

Хотя некоторые люди склонны оборачивать классы Entity Framework в свои бизнес-объекты, я обычно советую этого не делать.

Я понимаю, что это улучшает разделение бизнес-логики и доступа к данным, но я думаю, что это обычно не стоит затрат на дублирование всех типов сущностей.

Какова цель ИЛИ картографа? Он предназначен для сохранения бизнес-объектов без необходимости в сложном слое доступа к данным, который вручную сопоставляет объекты с базой данных. Если вы оберните классы Entity Framework, вы будете использовать только половину полученного удобства.

И, наконец, связь между доступом к данным и бизнес-логикой не так уж и тесна с частичными классами. Не так давно я за несколько часов без особых проблем изменил проект, включающий около 30 сущностей из Entity Framework в LINQ to SQL.

Answer 2

Я не понимаю, почему это будет плохо практика. Это может быть неудобно в зависимости от того, как вы собираетесь использовать объекты EF.

У меня есть частичные классы для реализации логики BIZ в объектах EF, использующие интерфейс для обеспечения уровня абстракции.

например.

public partial class Client : IClient
{
   void DoSomething();
}

// then an EF generated object ...
public partial class Client
{
 // ...
}

Моя единственная проблема - сериализация объектов. В моем случае сериализация в JSON с использованием WCF. Это невозможно без создания промежуточного DTO как отдельного класса / объекта или как анонимного типа.

Если вы заинтересованы в сериализации, взгляните на другой мой вопрос: Сериализация объектов Entity Framework в JSON