spring.net有什麼用？

Question

我們正在開發一個使用Silverlight和WCF服務的應用程序。是否使用Spring.Net對我們有利？

Answer 1

如果您想要更改應用程序的大塊而不必重寫構造函數，則DI框架可能會有用。例如，您可能希望使用您將通過界面公開的慧星流式服務，然後再決定使用MQ或RendezVous等專用通信系統。然後你將編寫一個適配器給Mq，這個適配器尊重普通的外觀，只需要改變spring配置來使用Mq實現而不是Comet。

但是對於tony的小馬的愛，不要使用Spring.Net爲每個視圖創建MVVM/MVP/MVC綁定，否則您將進入一個痛苦的世界。

與parcimony一起使用時，DI是一個很好的工具，請不要因爲您的開發人員的理智而終止於243個彈簧配置文件。

Answer 2

我認爲如果您在代碼中做的更多，而不是使用標記來進行綁定等，並且BAL/DAL DI可以幫助解決問題，因爲它可以注入正確的業務組件引用（作爲一個示例）。 DI還有許多其他的實際優點，但是你必須在代碼中做更多的事情，而不是在標記中做更多事情。

Answer 3

使用IOC容器（如Spring.Net）是有益的，因爲它使您能夠通過交換應用程序接口的模擬或特殊測試實現來單元測試部分UI。從長遠來看，這應該會讓您的應用程序更易於維護以便未來的開發人員使用。

Answer 4

就我個人而言，我推薦使用Castle或Unity，因爲我已經與他們取得了巨大的成功，並且發現他們都是不同的，出色的IOC框架。

除了IOC組件之外，它們還提供其他漂亮的工具（例如Castle中的AOP，Unity中的Interface interception），您將來無疑會找到它的用處，並且從一開始就有一個IOC框架總是比試圖改裝它容易得多。

它的設置和配置非常簡單，儘管個人而言我並不是XML配置方式的狂熱愛好者，因爲其中一些配置文件可能變成完全的惡夢。很多人會告訴你，如果你打算交換組件，唯一值得的做法是，但爲什麼不這樣做呢？無論如何，你決定你以後需要這樣做。擁有它並且不使用它比擁有它並且需要它更好。如果您擔心我在網絡上的許多博客文章中看到的perf perf命中，人們會比較各種IOC框架的速度，除非您正在創建腦外科手術機器人或美國導彈防禦平臺，否則不會是問題。

Answer 5

> >「正在使用Spring.Net對我們有利嗎？」

我認爲您的問題的精神實質上更多地是質疑使用IoC/DI框架與根據需要手動管理依賴關係的好處。我的迴應將更多地關注IoC/DI的原因和原因，而不是關於使用哪個具體框架。

正如Martin Fowler在最近的一次會議上提到的，DI允許您將配置與使用分開。對於我來說，根據配置和使用情況將DI作爲單獨考慮事項來考慮是開始提出正確問題的好方法。您的應用程序是否需要爲您的依賴項配置多個配置？您的應用程序是否需要通過配置修改行爲的功能？請記住，這意味着依賴關係在運行時被解析並且通常需要一個很好的XML配置文件，因爲可以在不需要重新編譯程序集的情況下進行更改。就個人而言，我不是基於XML的依賴關係配置的粉絲，因爲他們最終被視爲「魔術串」。因此，如果最終拼錯類名等，則存在引入運行時錯誤的風險。但是，如果您需要能夠即時進行配置，那麼今天可能是最好的解決方案。

另一方面，像Ninject和StructureMap這樣的DI框架允許流暢的代碼內依賴性定義。您失去了即時更改定義的能力，但您可以從編譯時驗證中獲得額外的好處，這是我更喜歡的。如果您希望從DI框架中解決依賴關係，那麼您可以從等式中消除基於XML的框架。

從Silverlight角度來看，DI可以以各種方式使用。最明顯的是定義View與ViewModels的關係。然而，更深入的是，您可以定義驗證和RIA上下文依賴關係等。擁有配置類中定義的所有依賴關係，可以讓代碼免於需要知道如何獲取/創建實例，而是關注使用情況。不要忘記容器可以根據你的配置管理每個對象實例的生命週期。因此，如果您需要共享某個類型的實例（例如Singleton，ManagedThread等），則可以通過聲明與該容器一起註冊的每個類型的生命週期範圍來支持該實例。

我剛剛意識到此時我在咆哮，我很抱歉。希望這可以幫助！