在业务逻辑层中使用实体框架生成的类
我有一个使用三层架构的 ASP.net (C#) 项目。我开始在 DAL 中使用实体框架，问题是实体框架生成的类可以在业务逻辑层中使用到什么程度？
直接使用它们是个好主意，还是我应该创建自己的业务对象并从实体框架映射到它们（db->O/RM->BO）？
I have a ASP.net (C#) project that is using a three layer architecture. I started to use Entity Framework in my DAL and the question is to what extent classes generated by Entity Framework can be used in the Business Logic Layer?
It is a good idea to use them directly or should i create my own business objects and map to them from Entity Framework(db->O/RM->BOs)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在我看来，EF 对象将映射到您的对象。这具有较高的开发成本，但带来了持久性无知和解耦的额外好处。从长远来看，如果业务需要切换到不同的持久性解决方案，这种解耦可以转化为显着的敏捷性和现实世界的节省。如果没有解耦，EF 对象可能会深深嵌入 BLL 甚至表示层中，从而需要进行大量重构。在这种情况下，企业甚至可能不会考虑切换持久性解决方案，这可能会导致企业竞争力下降。
以较高的开发成本获得这种收益的决定取决于企业愿意承担的风险大小。我建议您咨询项目专员，并利用您的最佳判断以技术方式解释他们的战略目标。
In my opinion, the EF objects would be mapped to yours. This has a higher development cost, but gives the added benefit of persistence ignorance and decoupling. This decoupling can translate to significant agility and real world savings in the long-run, should the business need to switch to a different persistence solution. Without the decoupling, the EF objects can become deeply embedded in the BLL and even presentation layers, requiring a huge refactoring. In such a case, the business might not even consider switching persistence solutions, which could cause the business to be less competitive.
The decision to reap this benefit at the higher development cost depends on the amount of risk the business is willing to take. I suggest you consult with the project commissioners and use your best judgement to interpret their strategic objectives in a technical way.
使用生成的类作为业务对象应该是足够合理的。生成的类是部分的，因此您可以根据需要轻松扩展它们。有时我发现使用接口是一个更好的选择。
It should be reasonable enough to use the generated classes as your Business Objects. The generated classes are partial so you can easily extend them as you please. Sometimes I find it a nicer option however to use interfaces.
我刚刚开始使用 EF 2.0（在 .Net 4.0 beta 2 中），它可以使用 POCO 类作为 EF 实体。即您现在可以在 EF 2 中使用持久性无知类。
我认为这还没有完全准备好，因为在使用 Visual Studio 2010 beta 2 时我无法遵循 PDC 2009 的演示，但请留意 ADO.Net 团队博客。
I have just started on EF 2.0 (in .Net 4.0 beta 2) and it has the facility to use POCO clases as EF entities. i.e. You can now use persistence ignorant classes in EF 2.
I think this is not fully ready yet, as I couldn't follow the presentation from PDC 2009 when working in Visual Studio 2010 beta 2 but keep a watch out for this at ADO.Net team blog.
您可能需要查看持久性忽略 (POCO) 适配器实体框架。这是 EF 团队成员的一个开源项目，为 EF 1.0 带来了 POCO 支持。 EF 4.0 将提供开箱即用的 POCO 支持，但该项目只是权宜之计，直到 2010 年 .NET 4.0 发布为止。
You may want to look at the Persistence Ignorance (POCO) Adapter for Entity Framework. This is an open-source project from a member of the EF team that brings POCO support to EF 1.0. EF 4.0 will have POCO support out-of-the-box, but this project serves as a stop-gap measure until .NET 4.0 drops in 2010.