使用Entity Framework中生成的对象作为业务对象是不好的做法吗?在Entity Framework对象周围编写一个辅助包装器,然后在层之间传递它会更好吗?
例如,编写我自己的POCO Person,它接受我生成的Entity Framework对象EFPerson之一来初始化POCO Person对象?
答案 0 :(得分:4)
虽然有些人倾向于将Entity Framework类包装到他们的业务对象中,但我通常建议不要这样做。
据我所知,这改善了业务逻辑和数据访问的分离,但我认为这通常不值得复制所有实体类型的开销。
OR映射器的用途是什么?它是持久化业务对象而无需手动将对象映射到数据库的复杂数据访问层。如果您包装Entity Framework类,您将只使用一半获得的便利。
最后,数据访问和业务逻辑之间的耦合并不像部分类那样紧密。不久前,我在几个小时内将涉及约30个实体的项目从实体框架更改为LINQ to SQL,没有出现重大问题。
答案 1 :(得分:2)
我不明白为什么它会糟糕练习。根据您打算如何使用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