使用 Entity Framework 生成的对象作为业务对象是不好的做法吗？围绕 Entity Framework 对象编写一个辅助包装器，然后在层之间传递是否更好？
例如，编写我自己的 POCO Person 接受我生成的 Entity Framework 对象之一 EFPerson 来初始化 POCO Person 对象？
【问题讨论】：
标签： .net database entity-framework .net-3.5
虽然有些人倾向于将实体框架类包装到他们的业务对象中，但我通常建议不要这样做。
我知道这改进了业务逻辑和数据访问的分离，但我认为这通常不值得复制所有实体类型的开销。
OR 映射器的用途是什么？它是持久化业务对象，而不需要手动将对象映射到数据库的复杂数据访问层。如果你包装实体框架类，你将只使用获得的便利的一半。
最后，数据访问和业务逻辑之间的耦合在部分类中并不是那么紧密。不久前，我在几个小时内将一个涉及大约 30 个实体的项目从 Entity Framework 更改为 LINQ to SQL，没有出现重大问题。
【讨论】：
我不明白为什么它会是 不好的 做法。根据您打算如何使用 EF 对象，这可能会很尴尬。
我有部分类在 EF 对象中实现 BIZ 逻辑，使用接口来提供一定程度的抽象。
例如。
public partial class Client : IClient
{
void DoSomething();
}
// then an EF generated object ...
public partial class Client
{
// ...
}
我遇到的唯一问题是序列化对象。就我而言，使用 WCF 序列化为 JSON。如果不将中间 DTO 创建为离散类/对象或匿名类型，这是不可能的。
如果您对序列化感兴趣，请在此处查看我的另一个问题：Serialize Entity Framework objects into JSON
【讨论】：