0

我经常遇到需要将 linq2sql 对象从一个 WPF 窗口传递到另一个窗口的情况。

例如，我有一个带有 linq2SQL 对象列表的窗口。该列表是从“Window_Loaded”事件中公开声明的 DataContext 绑定的。双击这些项目之一，将打开第二个窗口，可以编辑该对象。在打开选定对象时，将传递给第二个窗口的属性。在用户进行了一些更改后，他决定放弃更改并关闭第二个窗口。

现在，由于输入字段直接绑定到 Linq2SQL 对象，因此更改的值仍然存在。

在这种情况下，最佳做法是什么？将新创建的对象从新创建的 DataContext 传递到第二个窗口会更好吗？然后，当需要更改时，我必须以某种方式刷新第一个窗口上的列表。

或者我可以使用第一个窗口的对象列表中已经绑定的对象并将其直接传递给第二个窗口吗？

我知道当我必须重新加载对象时我可以刷新对象

DB.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues, MyObject);

最佳做法是什么？

4

1 回答 1

1

这个问题更笼统，触及到一个重要问题：在不同类型的应用程序中，哪种生命周期策略最适合 linq2sql 数据上下文。

对于 Web 应用程序，这个问题有一个简单的答案：“per-httprequest”生命周期策略是最方便的。

在您的情况下，一个 WPF 应用程序，我知道有两种方法：

  1. 在“每个应用程序的生命周期”策略中，您将为应用程序的生命周期创建单个数据上下文。虽然从技术上讲这是可行的，但内存消耗存在潜在问题 - 随着应用程序检索越来越多的数据，数据上下文中的第一级缓存会不受控制地增长，并且可能在某个时候耗尽资源

  2. 在“每个演示者（视图）”策略中，您在每个演示者（视图模型）（或视图，如果您不遵循 mvvm）中创建一个新的数据上下文，这意味着两个不同的视图不共享相同的上下文. 我会说这是推荐的方法，不存在不必要的资源问题的风险，但是，您需要一种额外的机制来在视图之间传递事件，以便在数据更改时可以刷新视图。

请注意，您所有的业务逻辑都应该不知道实际的策略。为此，让您的数据上下文（例如通过构造函数）注入到任何使用它的类中。根据实际策略，将适当的上下文注入到业务类中。这样，您甚至可以在某天更改生命周期管理策略，而无需重构您的业务代码。

于 2013-07-05T08:41:16.477 回答