與框架依賴有關的一些問題

Question

我有一些與框架依賴有關的問題。一般來說，最佳編碼實踐認爲，不要使用特定於框架的代碼來混淆名稱空間。對於例如在Spring的情況下，所有的依賴項都應該保存在配置文件中，並且在應用程序代碼中沒有特定於Spring的代碼（並且這是在Spring註釋中偏好spring config xml文件的原因之一）。在puremvc的情況下，它總是最好不要在mxml中混合使用puremvc代碼，所以您的視圖可以與任何框架一起使用。但我的問題是

1. 如果我們從代碼中移除彈簧或PureMVC的 無需更換任何 其他的框架，那麼你最終在幾豆 （春季的情況下）或 一些真正的可重複使用的意見（以puremvc的情況 ）。但是粘合豆或 視圖需要大量的編碼 努力，根據我的間接 框架依賴關係沒有 使用框架特定的API。

2. 如果我們更換彈簧，像微微容器等DI 0​​框架然後 還它需要大量的 或返工。這又導致 對框架的間接依賴。

那麼，爲什麼它不好使我們的應用程序名稱空間與框架特定的api混亂？只要我們可以編寫特定於框架的api（如果它真的可以大大減輕我們的編碼工作）。

據我說，只是不應用混合應用程序名稱空間與框架特定的api不會使您的應用程序可移植爲其他框架。想想如果你想用spring mvc移動你現有的精心設計的struts應用程序，以及它需要做多少努力。

期待其他讀者的看法。

Answer 1

與軟件開發中的所有抽象一樣，當你使用框架時，你只是簡單地移動'問題'。框架負責處理某些事情，因此應用程序的其他部分不需要知道如何執行該操作。例如。如果使用依賴注入，那麼注入的類不需要知道如何創建它們的依賴關係，而是由依賴注入框架處理。

但這隻意味着知識/責任被移動。它永遠不會，re -moved。所以是的，當然你的代碼隱含地依賴於這個框架。但是，如果您將與框架相關的代碼移動到一個位置，甚至可能引入一些接口來包裝它，有時您可以使其代碼的其餘部分依賴於接口，類或框架，而不是特定的框架。

E.g.我在我的代碼中介紹了一個IIocContainer接口，只有解決方法。實現此接口的對象擁有的知識如何來調用特定的Ioc/DI框架。但是這個知識只是在這一個對象中。我的應用程序的其餘部分（在需要的地方）只知道接口的IP地址，因此不依賴於特定的框架。如果我改變了框架，我只需要改變引用和配置（可能是XML而不影響代碼），並使用一個不同的對象來實現此容器的IIocContainer。當你談論直接影響你的代碼結構/架構（例如，通過基類，命名約定等）的框架時，這意味着抽象出特定的框架變得更加困難。你可能，但你基本上正在做的是圍繞另一個框架編寫你自己的框架。這不值得一提，因爲最終如果你要切換結構框架，它總是總是會很多工作，要麼直接重寫該框架，要麼將框架抽象出來。我認爲你可以把它簡單地理解爲：如果你正在使用一個框架來將「很多結構化管道工作」的問題轉移到該框架中（讓框架爲你處理管道），並且你切換框架，你會得到'很多結構性管道'問題。 :-)

Answer 2

我認爲它是一個軟件設計的基本原理，以保持您的關注點分離。就像你不想在MVC的模型層中查看代碼一樣，你不需要在你的應用程序代碼中使用容器特定的代碼。

你是對的，在很多情況下需要爲他們的工具編寫代碼。例如，如果您需要自定義類型，或者需要定製應用程序上下文，則可以編寫一些特定於Spring的代碼。沒有什麼不妥。關鍵是要將它與應用程序的其他功能片分開。

這並不保證「即時」便攜性。它所促進的是能夠「輕鬆」地將代碼移植到別處。在這種情況下「輕鬆」並不意味着沒有工作。相反，這意味着你不必開始刪除特定於Spring的東西，因爲你已經決定遷移到Pico。換句話說，您的核心業務功能保持不變，您只需在決定移動時移植配置或容器特定的依賴關係。