目前,对于ASP.Net的东西,我使用一个请求模型,其中每个请求创建一个上下文(仅在需要时),并在该请求的末尾处理。我发现这是一个很好的平衡,不需要做旧的使用每个查询模型和没有永远的上下文。现在问题是在WPF中,我不知道可以像请求模型那样使用任何东西。现在它看起来像永远保持相同的上下文(这可能是一场噩梦)或回到烦人的使用每个查询模型这是一个巨大的痛苦。我还没有看到一个很好的答案。
我的第一个想法是有一个打开和关闭(或任何名称)的情况,其中调用顶级方法(如Something_Click之类的事件处理方法)将“打开”上下文并在结尾处“关闭”它。由于我在UI项目中没有任何关于上下文的信息(所有查询都包含在部分类的方法中,这些方法“扩展”生成的实体类,有效地在实体和UI之间创建伪层),这似乎就像它会使实体层依赖于UI层。
因为我对州编程并不十分熟悉,所以真的很茫然。
增加:
我已经阅读了使用线程,但是 问题我只是一个上下文 坐在那里是错误和恢复。
假设我有一个更新用户的表单 信息,这是一个错误。该 用户表单现在将显示更改 到上下文中的用户对象 这是好事,因为它变得更好 用户体验无需重新输入 所有的变化。
现在如果用户决定去,该怎么办? 另一种形式。那些变化仍然存在 在上下文中。在这一点上,我 坚持使用不正确的用户 在上下文中的对象或我必须得到 用于告诉Context重置的UI 那个用户。我想那不是 可怕的(用户重新加载方法 上课?)但我不知道是不是 真的解决了这个问题。
答案 0 :(得分:0)
你有没有想过尝试一个工作单位?我有一个类似的问题,我基本上需要能够打开和关闭上下文而不暴露我的EF上下文。我认为我们正在使用不同的体系结构(我使用的是IoC容器和存储库层),所以我必须稍微删除这些代码以向您展示。我希望它有所帮助。
首先,当谈到“Something_Click”方法时,我的代码看起来像是:
using (var unitOfWork = container.Resolve<IUnitOfWork>){
// do a bunch of stuff to multiple repositories,
// all which will share the same context from the unit of work
if (isError == false)
unitOfWork.Commit();
}
在我的每个存储库中,我都要检查一下我是否在工作单元中。如果是的话,我会使用工作单元的上下文。如果没有,我必须实例化我自己的上下文。所以在每个存储库中,我都有类似的代码:
if (UnitOfWork.Current != null)
{
return UnitOfWork.Current.ObjectContext;
}
else
{
return container.Resolve<Entities>();
}
那么UnitOfWork怎么样?那里不多。我不得不删掉一些评论和代码,所以不要把这个课程视为完全正常工作,但是......在这里你走了:
public class UnitOfWork : IUnitOfWork
{
private static LocalDataStoreSlot slot = Thread.AllocateNamedDataSlot("UnitOfWork");
private Entities entities;
public UnitOfWork(Entities entities)
{
this.entities = entities;
Thread.SetData(slot, this);
}
public Entities ObjectContext
{
get
{
return this.Entities;
}
}
public static IUnitOfWork Current
{
get { return (UnitOfWork)Thread.GetData(slot); }
}
public void Commit()
{
this.Entities.SaveChanges();
}
public void Dispose()
{
entities.Dispose();
Thread.SetData(slot, null);
}
}
将此问题纳入您的解决方案可能需要一些工作,但这可能是一种选择。