使用 EntityFramework：每个演示者的上下文或 Windows 窗体应用程序的长对话模式？
现在我没有使用 MVP，我尝试了如下的长对话模式：
private void SaveItem(object sender, EventArgs e)
{
using (var transaction = _businessTransactionFactory.Create())
{
var currentMobileDevice = GetCurrentMobileDevice();
if (currentMobileDevice.Id == Guid.Empty)
{
transaction.MobileDeviceRepository.Save(currentMobileDevice);
}
else
{
transaction.MobileDeviceRepository.Update(currentMobileDevice);
}
transaction.Commit();
LoadData(transaction);
}
}
private MobileDevice GetCurrentMobileDevice()
{
return (MobileDevice)MobileDevicesBindingNavigator.BindingSource.Current;
}
我遇到的问题：
- 我总是必须与分离的实体一起工作。
使用分离的实体会强制 EntityFramework 更新所有列，而不是那些发生更改的列：
public void Update(T 实体) { if (_objectContext.ObjectStateManager.GetObjectStateEntry(entity).State == EntityState.Detached) { _objectSet.Attach(实体); _objectContext.ObjectStateManager.ChangeObjectState(实体, EntityState.Modified); } }
如何处理 Windows 窗体应用程序中的上下文？
两者的优点和缺点是什么？
For now I did not use MVP and I tried the long conversation pattern like this:
private void SaveItem(object sender, EventArgs e)
{
using (var transaction = _businessTransactionFactory.Create())
{
var currentMobileDevice = GetCurrentMobileDevice();
if (currentMobileDevice.Id == Guid.Empty)
{
transaction.MobileDeviceRepository.Save(currentMobileDevice);
}
else
{
transaction.MobileDeviceRepository.Update(currentMobileDevice);
}
transaction.Commit();
LoadData(transaction);
}
}
private MobileDevice GetCurrentMobileDevice()
{
return (MobileDevice)MobileDevicesBindingNavigator.BindingSource.Current;
}
Problems I encountered:
- I am always have to work with detached entities.
Working with detached entites forces EntityFramework to update ALL columns instead of those that changes:
public void Update(T entity) { if (_objectContext.ObjectStateManager.GetObjectStateEntry(entity).State == EntityState.Detached) { _objectSet.Attach(entity); _objectContext.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified); } }
How do you handle the context in a windows forms application?
What are pros and cons of both?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
典型场景是每个演示者都有新的上下文，其中演示者可以处理多个视图，以防同一数据有不同的视图。 MSDN 杂志上有一篇关于此的好文章。它针对 NHibernate 的会话，但 EF 的上下文管理应该遵循相同的方法来准确解决您在分离实体方面遇到的问题。
Typical scenario is new context per presenter where presenter can handle more than one view in case of different views on the same data. There is very nice article about this in MSDN magazine. It targets NHibernate's session but EF's context management should follow the same approach to solve exactly the problems you are encountering with detached entities.
看一下这篇文章：http://msdn.microsoft.com/en-我们/library/ff714955.aspx
这向您展示了一种通过 EF 使用存储库和工作单元模式的方法。不要直接在演示器中使用 unitofwork 实现，而是使用 IoC 容器（如 castle.windsor）进行 IUnitOfWork 的构造函数注入。除了干净且可扩展的架构之外，您还将获得一个非常好的好处：castle.windsor 为您提供（与大多数 IoC 框架一样）注册组件的生命周期选项，例如单例或瞬态。因此，只需一行代码即可更改所有实现 IUnitOfWork 的演示者的生命周期。您可以使用单独的工作单元实例或同一实例来启动每个演示者。
您需要代码示例吗？顺便说一句，我正在开发一个开源 github 示例，用于以干净的方式在可扩展架构中实现 EF。我与 ADO.NET 团队的 Scott Allen 进行了交谈。他会参加。
亲切的问候，
乌里
Take a look at this article: http://msdn.microsoft.com/en-us/library/ff714955.aspx
This shows you one approach to use the repository and unit of work pattern with EF.Instead of using the unitofwork implementation directly in your presenter, make an constructor injection of IUnitOfWork with an IoC container like castle.windsor. besides a clean and scalable architecture you will have a one very nice benefit: castle.windsor offers you (as the most IoC frameworks do) lifetime options for the registered components for example singleton or transient. so it takes you just one line of code to change the lifetime for all presenters implementing the IUnitOfWork. you would be able to initiate each presenter with an seperate instance of unitofwork or with the same instance.
do you need a code sample? by the way, i'm working on an open source github sample for implementing EF in a scalable architecture in a clean manner. i talked to Scott Allen from the ADO.NET Team. He will parcitipate.
Kind regards,
Uli