【发布时间】：2013-10-17 11:27:23
【问题描述】：
似乎将 N 层架构与 EF 一起使用意味着您必须为数据层的加载方法实例化一个新的 DbContext 对象，然后在尝试保存时实例化另一个对象。
这样做的下游含义是，在您保存时，在工作流开始时加载的实体不再处于状态，因此将调用保存到 ObjectStateManager.TryGetObjectStateEntry() 之类的东西会返回 false，在事实上，被保存的实体确实起源于数据库。结果是保存我们的编辑会导致添加。
这似乎是一个相当常见的架构中的一个相当常见的工作流程。有什么明显的我错过了吗？
【问题讨论】：
-
他们推荐用于 N 层数据访问的 WebAPI 或 WCF 数据服务。我不喜欢这些，所以我设法让
DbContext与Self Tracking Entities一起工作。现在我通过常规 WCF 发送我的实体，它们返回自我跟踪更改，我在我的((IObjectContextAdapter)dbContext).ObjectContext中ApplyChanges()并致电SaveChanges()。到目前为止，每个人都很开心。 -
在我们公司当前的项目中，我们的设置与您相同。 EF5/POCO/3 层； “缺点”是你必须通过你的层传递你的数据。但从长远来看，你的代码会更干净，更易于维护。哦，你失去了延迟加载！
-
@Tico 当您说“传递您的数据”时，您是指将 DbContext 对象连接到您的工作流中，以便您保存在加载实体的同一个实例上？
-
@TIco 延迟加载仍然可以为
server-only操作启用，例如报表查询和繁重的业务逻辑相关数据访问。 -
是的，类似的。让我试着解释一下。项目结构类似于这张图片（在google上找到）：（i.imgur.com/IIhBeX9.jpg）一层有POCO（VO层），另一层是BLL（业务逻辑层），DAL（数据访问层）和UI （随你喜欢）。可以这么说，UI 和 DAL 是“愚蠢的”。逻辑的责任在 BLL 内。所以，你必须查询数据库，传递给 BLL 和 UI（同样的方式）
标签： c# entity-framework n-tier-architecture