Re：UnitOfWork - 上下文可以解耦吗？

Question

我刚看完Julie Lerman关于Enterprise EF的视频。我特别喜欢自定义数据上下文的概念，因为它可以让我对各个UI进行更精细的控制。

Julie在她所有的存储库中都有CRUD方法，这对我的喜欢来说太过分了。我计划创建一个其他存储库派生自的通用存储库。我不喜欢她的UOW。

我计划将这种方法用于UOW，因为它与存储库有关：

https://codereview.stackexchange.com/questions/14226/generic-repository-and-unit-of-work-code

自定义数据上下文对象的相对条件：

1. 我们假设我创建：

   我。 CustomerLookup类，只具有完整Customer类的partials属性。

2. 我也创建了

   我。 CustomerLookup数据库上下文

   II。 OrdersLookup数据库上下文，它具有完整的Orders类，但忽略配置中关联的实体Shipping。

如果我按照上面链接中的UOW示例，UOW使用 FULL DbContext 来保存更改。

问题：

1. 当在API控制器中作为示例时，是否可以实例化UOW，以便可以使用特定的数据上下文：

   我。 CustomerLookupContext与UOW.CustomerLookupRepository.Update（customerLookup）？

   II。 OrdersLookupContext与UOW.OrdersLookupRepository.Update（订单）？

如果我无法将上下文对象与UOW解耦：

1. 我是否有更新上述部分类的问题;或
2. 使用整个DbContext会影响性能吗？或者，
3. 我不知道我在说什么＆amp;只使用UOW的完整DbContext？

由于

Answer 1

您应该只在应用中拥有一个dbcontext。有一些例外，比如当你需要访问两个不同的数据库时，但即便如此，我更喜欢使用SQL Server同义词将它们映射到一个数据库中。

在应用中添加多个上下文存在非常实际的问题。您将获得许多编译器错误，并且必须处理命名空间冲突。它可以解决它，但这是一个巨大的痛苦。

为不同的用途制作不同的上下文没有任何好处。 dbcontext的重点是，您可以拥有对数据库的完全访问权限，在不同实体中进行更改，然后在一个操作中保存所有更改。

你认为你获得了什么？它不像将整个数据库加载到内存中。