在业务逻辑层中使用实体框架生成的类

Question

我有一个使用三层架构的 ASP.net (C#) 项目。我开始在 DAL 中使用实体框架，问题是实体框架生成的类可以在业务逻辑层中使用到什么程度？

直接使用它们是个好主意，还是我应该创建自己的业务对象并从实体框架（db->O/RM->BO）映射到它们？

Answer 1

在我看来，EF 对象将映射到您的对象。这具有较高的开发成本，但带来了持久性无知和解耦的额外好处。从长远来看，如果业务需要切换到不同的持久性解决方案，这种解耦可以转化为显着的敏捷性和现实世界的节省。如果没有解耦，EF 对象可能会深深嵌入 BLL 甚至表示层中，从而需要进行大量重构。在这种情况下，企业甚至可能不会考虑切换持久性解决方案，这可能会导致企业竞争力下降。

以较高的开发成本获得这种收益的决定取决于企业愿意承担的风险大小。我建议您咨询项目专员，并利用您的最佳判断以技术方式解释他们的战略目标。

Answer 2

使用生成的类作为业务对象应该是足够合理的。生成的类是部分的，因此您可以根据需要轻松扩展它们。有时我发现使用接口是一个更好的选择。

Answer 3

我刚刚开始使用 EF 2.0（在 .Net 4.0 beta 2 中），它可以使用 POCO 类作为 EF 实体。IE。您现在可以在 EF 2 中使用持久性无知类。
我认为这还没有完全准备好，因为在使用 Visual Studio 2010 beta 2 时我无法遵循 PDC 2009 的演示，但请注意这一点 ADO.Net 团队博客.

Answer 4

您可能想看看 实体框架的持久性忽略 (POCO) 适配器. 。这是 EF 团队成员的一个开源项目，为 EF 1.0 带来了 POCO 支持。EF 4.0 将提供开箱即用的 POCO 支持，但该项目只是权宜之计，直到 2010 年 .NET 4.0 发布为止。