存儲庫vs域服務

我越是探索DDD和存儲庫，我越感覺自己被吸引到域服務方法。存儲庫vs域服務

我的直覺中的某些東西並不喜歡這樣一個事實，即一個存儲庫（至少在我讀過的示例和文章中）不是單個語句的原子。

using (var customerRepository = GetCustomerRepository()) 
    { 
     customerRepository.AddCustomerForDelete(someCustomer); 
     customerRepository.SaveChanges(); 
    }

這裏有一堆我不喜歡的東西。一般來說，存儲庫本身成爲一個問題，必須維護（它是IDisposable並需要「提交」）。看起來我並沒有把持續性問題抽象得很多。

，似乎坐在我的直覺更好

一個更簡單的方法是：

GetCustomerService().DeleteCustomer(someCustomer);

它的原子。沒有存儲庫的實例來維護，處理或保存更改。如果你真的真的需要工作的支持單元上的聚合根單人操作之外，將某些類型的數據範圍的支持（類似於一個TransactionScope）：

using(var ds = new DataScope()) 
{ 
    // both of these happen under the same underlying DbConnection or whatever 
    GetCustomerService().DeleteCustomer(someCustomer1); 
    GetCustomerService().DoSomethingElse(someCustomer2); 
}

在兩個以上，例如起見，可以說他們在某個業務控制器中，而數據訪問的底層機制（坐在存儲庫或服務實現中）是一個實體框架ObjectContext。而客戶是一些聚合根。

請告訴我，存儲庫方法更好。

謝謝。

來源

2010-12-20 Jeff

+1;不同意，但我喜歡這個問題 – Marijn 2010-12-21 14:39:48

我想說，你只看到了存儲庫模式的天真例子。沒有什麼說知識庫應該有原子方法。

我的做法是相當多的，以你的Datascope公司的做法相同：

using(var uow = UoW.Begin()) 
{ 
    var customerRepo = new CustomerRepository(uow); 
    customerRepo.Remove(someCustomer); 
    uow.Commit(); 
}

（我的做法是基於麥Nilssons NWorkspace的想法在他的書中應用領域驅動設計和模式）

這樣，我可以將不同類型的UoW傳遞給我的存儲庫。例如基於EF4的uow或linq到基於對象的uow，並且仍然在存儲庫內使用相同的linq查詢。

來源

2010-12-20 08:51:15

你似乎用Unit Of Work代替了我的問題。 – Jeff 2010-12-20 15:27:12

Roger解決了他的UoW的真正擔憂：「維護受業務事務影響的對象列表，並協調寫出更改和解決併發問題。」（福勒）。這是在大多數非平凡應用程序中需要解決的_事務性變化_相關_業務對象。 – Marijn 2010-12-21 14:37:53

在現代ORM支持的數據訪問層中，不應該由ORM本身來協調事務性更改，因爲在大多數情況下，單個對象/實體圖正在保存？ – Jeff 2010-12-21 14:59:43

存儲庫vs域服務

回答

相關問題