Linq to Sql 中的 UoW 模式失去数据绑定的可能性
我目前正在开发我的第一个 Linq-to-Sql 应用程序。 我已经实现了具有较短 dataContext 生命周期的数据访问方法，如下所示：
public IProduct GetByCode(string code)
{
using (var db = new dataContext())
{
return db.Products.SingleOrDefault(e => e.Code == code);
}
}
我想知道如何获取 clr-properties 的更改通知。 当您只有一个 dataContext 时，这不是问题。
所以问题是：如何获取实体的内存变化？！
我有一个可以在两个不同屏幕中修改的实体。一个屏幕中的更新应该在另一个屏幕中可见。我看到的唯一可能性是让 dataContext 与两个屏幕具有相同的生命周期，这取决于应用程序的生命周期。
我感觉到工作单元模式（每个请求）和完整的数据绑定功能之间存在摩擦。请告诉我我错过了什么......
I'm currently working on my first Linq-to-Sql app.
I've implemented the data-access methods with a short dataContext lifetime like this:
public IProduct GetByCode(string code)
{
using (var db = new dataContext())
{
return db.Products.SingleOrDefault(e => e.Code == code);
}
}
I'm wondering how to get change notifications of clr-properties.
When you have a single dataContext this is not a problem.
So the question is: How do I get in-memory changes of an entity?!
I have an entity which can be modified in two different screens. Updates in one screen should be visible in the other. The only possibility I see is to let the dataContext have the same lifetime as both screens, wich comes down to application lifetime.
I feel friction between the Unit of Work pattern (per request) and full databinding capabilities. Please tell me what I'm missing...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
LINQ to SQL 生成的类实现 INotifyPropertyChanged，因此您可以使用它来监视内存中原始对象的更改。
但是，您的两个屏幕都需要指向同一个实例，而不是拥有自己的副本（听起来是这样吗？）。
您没有说明您的 UI 屏幕使用哪种类型的绑定：如果它是 WPF/Silverlight 并且您正在使用绑定，您可能需要使用 MVVM 方法，其中数据源为两个屏幕共享。
LINQ to SQL generated classes implement INotifyPropertyChanged so you can use that to monitor for changes to the original object in memory.
However, both of your screens would need to be pointing at the SAME instance, not having their own copies (which sounds like this is the case?).
You don't say what type of binding your UI screens use: if it's WPF/Silverlight and you are using binding, you may want to use a MVVM approach, where the data source is shared for the two screens.