0

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

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

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

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

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

  1. 假设我创建：

    一世。仅具有完整 Customer 类的部分属性的 CustomerLookup 类。

  2. 我也创作

    一世。CustomerLookup 数据库上下文

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

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

问题：

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

    一世。CustomerLookupContext 与 UOW.CustomerLookupRepository.Update(customerLookup)？

    ii. OrdersLookupContext 与 UOW.OrdersLookupRepository.Update(order) ？

如果我无法将上下文对象与 UOW 分离：

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

谢谢

4

1 回答 1

1

一个应用程序中应该只有一个 dbcontext。也有例外，例如当您需要访问两个不同的数据库时，但即便如此，我还是更喜欢使用 SQL Server Synonyms 将它们映射到单个数据库中。

在应用程序中放置多个上下文存在非常实际的问题。你会得到很多编译器错误并且必须处理命名空间冲突。可以解决它，但这是一个很大的痛苦。

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

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

于 2012-09-27T17:48:42.197 回答