1

想象一下，我有一种像下面这样的方法，它使用一些策略来创建新产品并将它们保存在 Db 中。

一切都是作为工作单元的一部分发生的。

（我的担心和）问题： 我担心将 UnitOfWork 实例作为参数传递给策略并提交根方法中的更改是否可以或可以预防？如何避免将 UnitOfWork 实例作为参数传递给策略，但仍使它们作为工作单元的一部分工作？

（我不喜欢有人可以错误地调用 .Commit 内部策略实现的事实 - 我不想要）

public void DoTheJob(CustomerRequest req)
{

 var materialsPikcerStrategyFactory = new PickerStrategyFactory();
 var productionStrategyFactory = new ProductionStrategyFactory();

 var materialsPickerStrategy = materialsPikcerStrategyFactory.GetStrategy(req); 
 var productionStrategy = productionStrategyFactory.GetStrategy(req);

 using (var uow = new UnitOfWorkFactory() )
 {
    var materials = materialsPickerStrategy.PickMaterials(req, uow);
    var products = productionStrategy.CreateProductsWith(materials, uow);
    uow.Commit();
 }

}


puplic abstract class MaterialsPickerStrategy 
{

 // Picks some material entities from Db and modifies some of its properties before usage
 public abstract ICollection<Material> PickMaterials(CustomerRequest req, IUnitOfWorkFactory uow);

}

public abstract class ProductionStrategy
{
 // Gets the materials and creates some new instances by ADD'ing them to the repository
 public abstract void CreateProductsWith (ICollection<Material> materials, IUnitOfWorkFactory uow);
}
4

2 回答 2

1

我将有一个 UnitOfWork 作为依赖项传递给执行提交所需的任何类，在你的情况下，如果我理解你不想成为你的策略。

UnitOfWork 应该知道如何提交更新，因为它会引用某种数据上下文。也许和实体框架模型、DBContext 等有关。

如果它们不应该提交，你的策略不应该知道 UnitOfWork。我猜也许您使用 UnitOfWork 将您的数据上下文暴露给您的策略。

您的策略和您的 UnitOfWork 都应该引用相同的数据上下文。然后你的策略与上下文和其他一些例程一起工作，它可能使用了许多策略，最后会引用 UnitOfWork 来提交它。

如果您使用的是 IOC 框架，这一切都非常简单，因为您会将数据上下文的生命周期范围指定为 PerRequest，并将其作为依赖项传递给您的两个类。当框架将该依赖项注入到您的类中时，它将使用相同的实例，因此您的策略将写入工作单元持有的相同实例。这样，您通过策略对数据所做的更改与工作单元将要提交的更改相同。如果您对 IOC 非常熟悉，您实际上可以注入给定类所需的上下文的各个部分，从而进一步隔离依赖关系。

于 2013-01-11T18:21:46.940 回答
1

您的代码似乎只使用工作单元而不使用存储库。它们通常一起使用来解决您的问题。存储库负责从数据库中获取数据或注册当前工作单元中的更改，而工作单元负责提交已注册的更改。这将允许您将存储库传递给您的策略，并且策略将无法访问工作单元。

就 EF 而言，ObjectContext/DbContext可以被视为工作单元，ObjectSet/DbSet可以被视为存储库。如果您有自定义工作单元和自定义存储库，它们必须都共享单个 EF 上下文实例。

于 2013-01-11T18:24:23.503 回答