Re：UnitOfWork - 上下文可以分離嗎？

Question

我剛剛在Enterprise EF上觀看了Julie Lerman的視頻。我特別喜歡自定義數據上下文的概念，因爲它可以讓我更細化地控制各個UI。

Julie在她所有的倉庫中都有CRUD方法，這只是對我喜歡的編碼太多而已。我打算創建一個其他存儲庫派生自的通用存儲庫。我不喜歡她的UOW。

我打算用這種方法來UOW，因爲它涉及到存儲庫：

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

含自定義數據上下文的相對條件對象：

1. 假設我創建：

   i。 CustomerLookup類只具有完整Customer類的部分屬性。

2. ，我也創建

   我。 CustomerLookup db上下文

   ii。 OrdersLookup數據庫上下文具有完整的Orders類，但忽略配置中的關聯實體Shipping。

如果我按照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？

感謝

Answer 1

你只應該永遠在一個應用程序一個的DbContext。有一些例外情況，例如當您需要訪問兩個不同的數據庫時，但即使如此，我仍然傾向於使用SQL Server Synonyms將它們映射到單個數據庫中。

在應用程序中放置多個上下文存在非常實際的問題。你會得到很多編譯器錯誤，並且必須處理命名空間衝突。有可能解決它，但這是一個很大的痛苦。

針對不同的用途製作不同的上下文沒有任何好處。 dbcontext的全部要點是您可以完全訪問數據庫，在不同實體中進行更改，然後將所有更改保存在一個操作中。

你認爲你正在獲得什麼？這不像它將整個數據庫加載到內存中。