从 BI 层引用实体框架组件是否可以接受？ [复制]答案

【问题标题】：Is it acceptable practice to reference entity framework assembly from the BI layer? [duplicate]从 BI 层引用实体框架组件是否可以接受？ [复制]
【发布时间】：2013-10-27 18:19:44
【问题描述】：

如果 EF 模型包含在单独的程序集中并由数据访问层引用/用于所有 DB 操作，是否也可以使用来自商业智能层的 EF 模型引用相同的程序集？为了简化从 DAL 到 BI 层的数据传输？

这将允许消除 DTO 对象，或者在我的情况下 Tuples 我用来将数据从 DAL 传输到 BI，因为 DAL 可以只返回 BI 已经“知道”的 EF 对象。问题是，从架构的角度来看，这是否会因为违反关注点分离或其他一些好的软件设计规则而受到反对？

【问题讨论】：

标签： c# entity-framework architecture dto

【解决方案1】：

这就是我不喜欢 EF 的原因。为了隐藏您正在使用 DB 的事实，您必须隐藏 EF 通过创建新类为您生成所有这些漂亮可爱的类的事实。

由于 EF 类具有可导航的关系，并且这些关系仅在实体附加到上下文时才有效，例如，您不能将它们通过网络传输到 API 客户端。

嗯，你可以，但是当你没有为 Get 调用添加相关记录时，他们会很生气。

就我个人而言，我将把泄漏的抽象抛在脑后。如果不完全（咳咳），那就在 DL 中隐藏你的羞耻。

【讨论】：

当然这完全不真实。
@HighCore：您是说导航属性通过网络断开连接？或者那部分是真的，而不是其余的？您是否声称 EF 没有完全泄漏？ Code first 可能是最接近不存在的 EF，我同意这一点。
在抱怨之前学会正确使用平台。如果您禁用延迟加载和代理创建，您可以通过 WCF 等完美地发送内容。是的，你必须.Include() 的东西，但这是完全可以接受的，IMO。
@HighCore：你可以接受，我不行。也不是任何使用 API 的人都希望包含正确的关系。我用过，很正常，谢谢。这是一个泄漏的抽象，不值得付出努力。如果你不说我无知，我们可以不同意。现在去堵住你的漏洞。