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

Posted 2023-02-24

【中文标题】在业务逻辑层使用实体框架生成的类

【英文标题】：Using Entity Framework generated classes in Business Logic Layer

【发布时间】：2010-12-20 10:57:59

【问题描述】：

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

直接使用它们是个好主意，还是我应该创建自己的业务对象并从 Entity Framework(db->O/RM->BOs) 映射到它们？

【参考方案1】：

您可能想查看Persistence Ignorance (POCO) Adapter for Entity Framework。这是一个来自 EF 团队成员的开源项目，它为 EF 1.0 带来了 POCO 支持。 EF 4.0 将提供开箱即用的 POCO 支持，但在 .NET 4.0 于 2010 年下降之前，此项目作为权宜之计。

【参考方案2】：

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

【参考方案3】：

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

【参考方案4】：

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

以更高的开发成本获得此收益的决定取决于企业愿意承担的风险程度。我建议您咨询项目专员，并以您的最佳判断从技术角度解释他们的战略目标。

【讨论】：

EF 生成的类被设计为可扩展并用作业务对象。如果您不喜欢它，您应该适当地更改 orm 或仅等待代码 EF 4。添加其他对象感觉不对。首先是 DB，然后是 ORM 类，然后是 BO，然后是视图模型。似乎很多。