.NET实体框架

Question

将实体框架中生成的对象用作业务对象是不好的做法吗？围绕实体框架对象编写一个二次包装，然后再通过层之间的更好？

例如，写我自己的POCO Person，它接受我生成的实体框架对象EFPerson中的一个来初始化POCO Person对象？

Answer 1

我不明白为什么会这样不好的做法。根据您打算如何使用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

Answer 2

虽然有些人往往在实体框架类包装到他们的业务对象，我通常会建议不要那样做。

我知道这改善了业务逻辑和数据访问的分离，但我认为这通常不值得重复所有实体类型的开销。

OR映射器的目的是什么？无需手动将对象映射到数据库的复杂数据访问层就能坚持业务对象。如果你包装了实体框架类，你只能使用获得的一半便利。

最后，数据访问和业务逻辑之间的耦合与部分类不紧密。不久之前，我在几个小时内将一个涉及大约30个实体的项目从实体框架改为LINQ to SQL，没有出现任何重大问题。