.NET实体框架

我不明白为什么 坏的 实践。根据您打算如何使用EF对象,这可能会很尴尬。

我有部分类来在ef对象中实现biz逻辑,使用接口来提供抽象级别。

如。

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

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

我唯一的问题是序列化对象。在我的例子中,使用wcf序列化到json中。如果不将中间数据创建为离散类/对象或匿名类型,则是不可能的。

如果您对系列化感兴趣,请看我这里的另一个问题: Serialize Entity Framework objects into JSON

虽然有些人倾向于将实体框架类包装到他们的业务对象中,但我通常建议不要这样做。

我理解这可以改进业务逻辑和数据访问的分离,但我认为这通常不值得复制所有实体类型的开销。

或映射器的目的是什么?它是持久化业务对象,而不需要复杂的数据访问层手动将对象映射到数据库。如果包装实体框架类,您将只使用获得的便利的一半。

最后,数据访问和业务逻辑之间的耦合与部分类没有那么紧密。不久前,我将一个涉及30个实体的项目从Entity Framework改为Linq,改为SQL,只用了几个小时,没有什么大问题。