如果这似乎是一个重复的问题,请提前道歉。这个问题是我能找到的最接近的问题,但它并不能真正解决我面临的问题。
我在 ASP.NET MVC4 应用程序中使用 Entity Framework 5 并尝试实现工作单元模式。
我的工作单元类实现IDisposable
并包含我的派生对象上下文类的单个实例DbContext
,以及许多存储库,每个存储库都派生自公开所有常用存储库功能的通用基础存储库类。
对于每个 HTTP 请求,Ninject 创建一个 Unit of Work 类的实例并将其注入控制器,并在请求完成时自动释放它。
由于 EF5 抽象了数据存储,而 Ninject 管理对象上下文的生命周期,因此它似乎是使用代码访问内存中实体对象的完美方式,而无需显式管理它们的持久性。换句话说,为了优化关注点分离,我设想我的控制器操作方法能够使用和修改存储库数据,而无需SaveChanges
事后显式调用。
我第一次(天真的)尝试实现这个想法,SaveChanges
在每个修改数据的存储库基类方法中调用了一个调用。当然,我很快意识到这既不是性能优化(尤其是在对同一个方法进行多次连续调用时),也不能适应操作方法直接修改从存储库中检索到的对象的属性的情况。
因此,我改进了我的设计,以消除这些过早的调用,SaveChanges
并在处理 Unit of Work 实例时将它们替换为单个调用。这似乎是 MVC 中工作单元模式最简洁的实现,因为工作单元自然地限定为请求。
不幸的是,在构建了这个概念之后,我发现了它的致命缺陷——在 a 中添加或删除的对象在被调用之前不会被反映,甚至在本地DbContext
也不会被反映。SaveChanges
那么,您对消费代码应该能够在不显式持久化对象的情况下使用对象的想法有何看法?而且,如果这个想法似乎有效,那么使用 EF5 实现它的最佳方法是什么?
非常感谢您的建议,
蒂姆
更新:根据@Wahid 的回复,我在下面添加了一些测试代码,这些代码显示了消费代码必须显式调用的一些情况SaveChanges
:
var unitOfWork = _kernel.Get<IUnitOfWork>();
var terms = unitOfWork.Terms.Entities;
// Purge the table so as to start with a known state
foreach (var term in terms)
{
terms.Remove(term);
}
unitOfWork.SaveChanges();
Assert.AreEqual(0, terms.Count());
// Verify that additions are not even reflected locally until committed.
var created = new Term { Pattern = "Test" };
terms.Add(created);
Assert.AreEqual(0, terms.Count());
// Verify that additions are reflected locally once committed.
unitOfWork.SaveChanges();
Assert.AreEqual(1, terms.Count());
// Verify that property modifications to entities are reflected locally immediately
created.Pattern = "Test2";
var another = terms.Single(term => term.Id == created.Id);
Assert.AreEqual("Test2", another.Pattern);
Assert.True(ReferenceEquals(created, another));
// Verify that queries against property changes fail until committed
Assert.IsNull(terms.FirstOrDefault(term => term.Pattern == "Test2"));
// Verify that queries against property changes work once committed
unitOfWork.SaveChanges();
Assert.NotNull(terms.FirstOrDefault(term => term.Pattern == "Test2"));
// Verify that deletions are not even reflected locally until committed.
terms.Remove(created);
Assert.AreEqual(1, terms.Count());
// Verify that additions are reflected locally once committed.
unitOfWork.SaveChanges();
Assert.AreEqual(0, terms.Count());