问题标签 [objectcontext]

我正在使用实体框架、SQL 和 C#。

我有一个名为 Client 的表和其他名为 clients_phone 的表。

我有一个带有 Xtragrid 的表单，并使用 BindingSource 将 IQueryable 绑定到网格。

然后，我想向我的客户添加一个新的 clients_phone。为此，我创建了一个 New Client()，然后添加了电话。

最后，我在 ObjectContext 中添加了新的 clients_phone，但是当我看到 Xtrag clients_phone 时没有显示。

知道会发生什么吗？

谢谢

我有一个 Web 服务，它向和从数据库公开操作。我正在为 DAL 使用实体框架 4。

我想知道处理进出数据库的操作的最佳方法是什么。最好不要让 ObjectContext 的实例保持活动状态，而是为对数据库执行的每个操作创建一个实例？这似乎是一种非常糟糕的处理方式，但我想不出另一种方法来跟上对数据库所做的更改。

如果我保持相同的上下文处于活动状态，它如何知道数据何时被修改？我知道在查询数据库时，ObjectContext 只是通过检查主键字段来检查记录是否已添加或删除（我是否正确？）。在这种情况下，我必须明确告诉它刷新特定对象，这不是很实用。

我正在考虑使用时间戳列的解决方案，并且 objectcontext 检查该列是否有更改。如果该列被修改，它会刷新数据。这样的解决方案是在 Entity Framework 4 中构建的吗？或者是否有人对我如何始终从数据库中获取最新数据而不为每个请求重新创建 ObjectContext 有任何其他建议？

我已经被这个问题困扰了一个多星期了。希望有人能指出我正确的方向。

我首先简要描述一下我的架构。

资产 1--->1 地址 *-->1 地区 *-->1 地区 *-->1 国家

包 1-->* 资产

使用自我跟踪实体 (STE) + WCF。

脚步：

1. 调用数据存储以获取资产列表。
2. 调用数据存储以获取软件包列表。
3. 用户选择一个包并为其分配一些资产。
4. 保存包。

在第 2 步中，调用使用地址的预先加载。

这是尝试调用时的错误

AcceptChanges 无法继续，因为对象的键值与 ObjectStateManager 中的另一个对象冲突。在调用 AcceptChanges 之前确保键值是唯一的。

编辑

在窥探之后，我发现这是一个 STE 问题。问题是您无法保留包含此处概述的同一实体的多个实例的图形。这是我的问题。

如何将实体添加到我的实体集合中。新实体可能具有包含与集合中已有的相同键的相关实体。即添加可能包含相同地址、区域、地区或国家实体的新资产。

这是我的约束：

1. 我必须使用导航集合，因为它会影响 UI。
2. 我无法预取将涉及的所有实体，因为数据集太大了。
3. 我必须能够随时拍摄实体的快照，以便保留历史记录并使用它来“撤消”任何更改。

我知道Diego B Vega建议的可能解决方案，但这些不是我可以用于我的解决方案的选项。有没有人有其他想法？

有一个 EF 上下文和一个 Testenity 我想让下面的测试工作。

我知道它可以与 SaveChanges() 一起使用，但我不想将Entity 保存到datasource。

从这个 MSDN 文档中解释...

当在 ObjectContext 上调用 SaveChanges 时，实体框架会生成一条 INSERT 语句并在数据源上执行。

如果 INSERT 操作成功，服务器生成的值将被写回到 ObjectStateEntry。当在 SaveChanges 执行结束时自动调用 AcceptChanges 时，将使用新的服务器生成的值计算永久 EntityKey。

我的代码中似乎没有发生这种情况。当我调用ObjectContext.SaveChanges()时，UpdateException会抛出一个InnerException.Message值：

“重复键值违反了唯一约束 student_term_data_pkey”

这是有问题的代码：

我已验证StudentTermData.Id在我的 Entity 数据模型中标记为 EntityKey。有没有人有任何想法或建议？

如果我有以下存储库：

我知道只有在触发查询时才打开连接：

如果是这种情况，我还需要让我的存储库实现 IDisposable 吗？

Visual Studio Code Metrics 当然认为我应该这样做。

我使用 IQueryable 是因为我将查询控制权交给了我的服务层（过滤器、分页等），所以请不要就我使用它的事实进行架构讨论。

顺便说一句 - SqlDataContext是我的自定义类，它扩展了实体框架的 ObjectContext 类（所以我可以有 POCO 方）。

所以问题 - 我真的必须实施 IDisposable 吗？

如果是这样，我不知道这是怎么可能的，因为每个方法共享相同的存储库实例。

编辑

我正在使用依赖注入（StructureMap）将具体存储库注入服务层。这种模式沿应用程序堆栈向下 - 我正在使用 ASP.NET MVC，并将具体服务注入到控制器中。

换句话说：

1. 用户请求网址
2. 控制器实例被创建，它接收一个新的 ServiceLayer 实例，该实例是用一个新的 Repository 实例创建的。
3. 控制器调用服务上的方法（所有调用都使用相同的存储库实例）
4. 一旦请求得到服务，控制器就消失了。

我正在使用混合模式将依赖项注入到我的控制器中，根据 StructureMap 文档，这会导致实例存储在 HttpContext.Current.Items 中。

所以，我不能这样做：

因为这破坏了 DI 的全部意义。

我希望这是有道理的。我有一个使用实体框架的 ASP.NET Web 应用程序。我在数据库中添加了几个自定义表，并创建了一个单独的项目来处理这些表的 CRUD 操作。我选择了单独的项目，因为我不希望将来对应用程序的升级覆盖我的自定义功能。

我的问题是这个。如何将我的自定义 ObjectContext 附加/组合到应用程序的 ObjectContext？我想使用相同的 UnitOfWorkScope（已经在应用程序中）来维护每个 HTTP 请求的一个 ObjectContext 实例。同样，出于上面列出的原因，我不想将我的 ObjectSet 添加到应用程序的 ObjectContext 中。

这是一些代码：

小部件.cs

WidgetObjectContext.cs

在我的 WidgetManager 类中，如果我使用应用程序的 ObjectContext，我会像这样查询我的表：

我想要的是做这样的事情：

我知道这行不通，但这就是我要完成的工作的要点。希望这足够清楚。谢谢。

是否有手动将 ObjectContext 清除/重置为其初始状态的方法？请注意，我不能只实例化一个新上下文。

这是使用实体框架的 1.0 版本。

谢谢

我有几个我想同时更新的实体。但是我想在每个类的部分类文件中为每个实体编写单独的更新方法并同时调用它们。例如：

我的问题是如何管理对象上下文？我要在调用UpdateAll() 的类中创建一个对象上下文，然后将它作为参数传递给每个单独的更新方法吗？或者我是否为每个更新创建一个新的上下文？我想使用相同的上下文，因为对象是相关的，这将减少更新所有记录的数据库调用。

我与一位资深的 .NET 架构师一起工作。在过去的 6 个多月里，我们进行了许多建设性的争论，总的来说，我在大多数讨论中都承认失败。我从和他一起工作中学到了堆栈。然而，我们目前在一个设计问题上存在分歧，我想要一些意见/建议，因为他没有设法让我相信他的立场，我会坚持我的立场，直到有人能给我证据证明我我错了。

我们使用 Entity Framework 4.0，并在不同的模型中同时使用持久性感知和自我跟踪实体。我们开始使用自跟踪实体来跟踪我们通过 WCF 线路序列化/反序列化到 Silverlight 应用程序的实体图的更改。它非常有效。我们还开始将自跟踪实体用于我们未跨 WCF 采用的模型，但许多仍然作为持久感知实体/模型。

我的同事认为 Entity Frameworks ObjectContext 应该保留尽可能短的时间。他坚持认为它应该只存在于执行查询所需的时间长度和持久化某些东西所需的时间长度。与实体完成的任何业务工作都应该独立完成。对于我们拥有的每个实体模型，我们都有一个查询类和一个持久类，它们都是 IDisposable 并且在实例范围内具有 ObjectContext 并且在方法中具有查询/持久性逻辑。我们在业务逻辑中使用这些查询/持久性类，而不是直接在业务逻辑中使用 ObjectContext。当这些类实例被构造时，ObjectContext 也是如此，而当 Disposed 时，ObjectContext 也是 Disposed。

现在首先考虑非自追踪实体：

我理解他为什么想要这个以及不希望有一个长时间运行的 ObjectContext，但我的问题是他总是希望将微不足道的业务逻辑从 ObjectContext 中分离出来，而且我们在设计下有一个单独的查询和持久性上下文意味着在我们的业务逻辑中没有对正在使用的实体进行 ObjectContext 状态跟踪。对于非自跟踪实体，这意味着如果我们在业务逻辑中修改实体，我们还必须在持久化之前手动设置实体的已修改状态。在持久化具有多个更改的复杂图形时，这是一个真正的痛苦。我也怀疑我们是否可以手动完成，而 EF 会自动完成。

对于我们的自跟踪实体，这种情况是相同的，因为仅在反序列化图形时才打开跟踪，因此当在执行查询的服务中工作时，与上下文分离，自跟踪实体仍然没有跟踪.

我的问题是，使用实体框架的最佳实践是什么以及应该如何设计实体框架 DAL？ObjectContext 应该存在多长时间？业务逻辑是否应该始终与 ObjectContext 分离？如果是这样，我们如何在与 ObjectContext 分离时进行状态跟踪？我正在考虑的一个选项是将我们所有的实体转换为自我跟踪实体，并使用一些图形遍历代码来遍历查询的图形并为图形中的所有实体打开跟踪，这样即使在服务端工作时自我跟踪也会打开（基本上模仿反序列化自跟踪实体图时发生的情况）......

我并不是建议我们长时间保留 ObjectContext，但是在查询和持久性之间分离工作并且失去 ObjectContext 状态跟踪的好处对我来说似乎很愚蠢......我们正在失去 EntityFramework 的一大好处。 ..

对不起，长篇文章......任何帮助表示赞赏。