存儲庫/ UoW - 使用或不使用？

Question

我知道這已經做了一百萬次，但我仍然有兩種想法：

1. EF - UoW / Repository - 服務 - Web或
2. EF - 服務 - 網絡

看起來UoW / Repository層是多余的，因為你可以模擬DbContext等。這將使實現簡單並使服務更接近EF似乎更通用。

有沒有人對此有任何好的建議？

我遇到的一個問題是，我將使用Ninject來連接它。 在網絡方面，如果我想將DbContext注入服務，則需要引用EF。 這似乎是錯的。

kernel.Bind<FunkySoftwareContext>().ToSelf().InRequestScope();

有沒有辦法抵消這種情況？

Answer 1

取決於你是否想要正確的抽象。

服務層不應公開數據庫實體。 它應該暴露適當的業務/域模型。 它們可能看起來也可能看起來不像db實體。

imho這就是存儲庫模式的好處。 它采用業務模型表示並將其轉換為數據庫/ orm可以使用的內容（反之亦然）。

但是，如果您已經確定從Entity框架加載的對象是您的域/業務模型的完美表示，那么請務必繼續並跳過存儲庫。

我在這里寫了一篇博客文章： http ： //blog.gauffin.org/2012/06/protect-your-data/

Answer 2

（這將是一個評論，但它變得太大了！）如果你有2個問題，你應該問2個問題。 如果這是一個Ninject問題，我會回答它，但標題不是。

在ninject方面，請參閱我應該在哪里注射Ninject 2+（以及如何安排我的模塊？） （包括鏈接到副本）。

總結是單個組合根管理到綁定過程是正確的，所以最終你會得到一些東西 （參見@jgauffin答案），這將是InRequestScope ，並且正確地說它在CR中。

其他方法（閱讀所有UOW MVC Repository InRequestScope Qs＆As）歸結為只將業務層服務類注入到Controller類中

1. 如果其下的某個烏龜使用DBContext可能是一種更好的方法來管理它，那么實現IDisposable一直向下。
2. （更理想的情況下）讓Controller以明確的方式顯式地提交任何UOW（並處理失敗）（這並不完全排除對Filters等的一些全部處理）。 我絕對不是說Controller應該直接與DBContext對話。

Answer 3

看起來像UoW / Repository層是多余的，因為你可以模擬DbContext等。這將使實現簡單並使服務更接近EF似乎更多功能

即使你自己現在重新使用Repository模式過度使用，EF本身也會使用DbContext實現UoW，使用DbSet實現Repository。 因此，不必在您的架構中添加UoW / Repository。

如果您在此處和此處需要更多建議。 甚至是Ayende的建議： 這里和這里