MVC IoC組件生活方式PerWebRequest

當我有人向我提及IoC容器時，我剛剛開始習慣於MVC，現在我感覺我已經下降了幾千英尺，需要重新爬升回去。我試圖忽略它們，但後來我閱讀了Component Lifestyle。這對我來說似乎是個大問題，正如所解釋的那樣，如果我的存儲庫Lifestyle設置爲Singleton而不是PerWebRequest，那麼數據庫更新的無限更改可能會泄漏。MVC IoC組件生活方式PerWebRequest

所以我的問題......有沒有辦法創建組件生活影響，而不使用IoC容器，或者是唯一的選擇？

來源

2009-07-21 dizzyguy

您始終可以創建一個實例作爲Singleton。然而，當談到倉庫時，我認爲沒有必要。但這不是使用IoC的真正目的。使用IoC將實現本身的代碼用戶分離出來。它可以讓測試變得更容易，因爲您可以根據自己的需要來調整和調整內容。另外，就我而言，我發現它對於其他用途也非常有用。以緩存爲例。在我的本地開發中，我使用Lucene.NET爲基於磁盤的緩存提供緩存實現。然後，當我推進我的開發和登臺平臺時，我使用標準的.net緩存實現。然後，當我推入產品時，我可能會使用Velocity或MemCached實現。自從我使用StructureMap（我的首選IoC容器）以來，我不必做任何奇怪的操作就可以從點A到點B.

看起來Component Lifestyle更像是一個設計決定而非IoC決定。這裏提到的用於管理對象生命的三種方法都可以在沒有IoC的情況下完成......但這可能是IoC（在某些情況下）的一個有趣副作用。

來源

2009-07-21 19:28:01

謝謝...解耦我的代碼是*好*但對我來說目前不重要。然而，跨請求的數據的完整性是至關重要的 - 我擔心的是，如果沒有IoC，我會以某種方式打開我的應用程序，以應對潛在的腐敗問題。（注意：我還沒有使用MVC實現一個真正的應用程序 - 只有四個或五個演示應用程序，我剛剛閱讀了兩本有關該主題的書 - 並且IoC容器主題將我引入循環） – dizzyguy 2009-07-21 19:37:26

「Your * SqlProductsRepository 「目前有這種Singleton生活方式，所以只要您的應用程序運行，您就可以保持單個LINQ to SQL * DataContext *，並跨所有請求共享它。這可能看起來很好......因爲到目前爲止所有的數據訪問都是隻讀的，但是當你開始編輯數據時會導致問題。「 - Pro ASP.NET MVC框架，第101頁 – dizzyguy 2009-07-21 19:41:44

如果在控制器或服務中實例化數據上下文的實例，並將其」注入「到您的存儲庫或該存儲庫中以進行該事務。 ..然後調用commit ...然後殺掉數據上下文的「你應該」是可以的我永遠不會在應用程序的生命週期中讓我的datacontext處於開放狀態，它不在事務範圍之外。 ..我發現這是一個安全的方式來做到這一點。 – 2009-07-21 22:21:20

MVC IoC組件生活方式PerWebRequest

回答

相關問題