我经常遇到需要将linq2sql对象从一个WPF窗口传递到另一个窗口的情况。
例如，我有一个带有linq2SQL对象列表的窗口。该列表是从“Window_Loaded”-event中的公共声明的DataContext绑定的。双击其中一个项目，将打开第二个窗口，并可以编辑对象。打开所选对象时，会将其传递给第二个窗口的属性。用户进行了一些更改后，他决定放弃更改并关闭第二个窗口。
现在因为输入字段直接绑定到Linq2SQL对象，所以仍然存在更改的值。
在这种情况下，最佳做法是什么？将新创建的对象从新创建的DataContext传递到第二个窗口是否更好？然后，当需要进行更改时，我必须以某种方式刷新第一个窗口上的列表。
或者我可以使用第一个窗口中对象列表中已绑定的对象并将其直接传递给第二个窗口吗？
我知道当我必须重新加载对象时我可以刷新对象
DB.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues, MyObject);
最佳做法是什么？
答案 0 :(得分：1)
问题更为笼统，触及了一个重要问题：生命周期策略最适合不同类型应用程序中的linq2sql datacontext。
对于Web应用程序，这个问题有一个简单的答案：“per-httprequest”生命周期策略是最方便的。
在您的情况下，WPF应用程序，我知道有两种方法：
在“每个应用程序的生命周期”策略中，您将为应用程序的生命周期创建单个数据上下文。虽然从技术上讲这是有效的，但是内存消耗存在潜在的问题 - 随着应用程序检索越来越多的数据，数据上下文中的第一级缓存在没有控制的情况下增长，并且可能在某些时候耗尽资源
< / LI>在“per-presenter（view）”策略中，您在每个演示者（视图模型）（或视图，如果您不遵循mvvm）中创建新的数据上下文，这意味着两个不同的视图不要共享相同的上下文。我说这是推荐的方法，没有不必要的资源问题的风险，但是，您需要一个额外的机制来在视图之间传递事件，以便在数据更改时刷新视图。
请注意，您的所有业务逻辑都应该不知道实际的策略。为此，请将您的数据上下文（例如构造函数）注入任何使用它的类。根据实际策略，将适当的上下文注入到业务类中。这样，您甚至可以在某一天更改生命周期管理策略，而无需重构业务代码。