春季錯失示例

我們的軟件商店有一個大型企業系統，其中一個部分是複雜的監控和日誌查看器工具。最近我們的一個teems重寫了它，因爲之前的版本確實缺乏一些基本功能。這真的很難看。春季錯失示例

既然這個團隊對企業的東西感到厭倦，他們聽說過IoC和Spring（「看起來很酷，你呢？」），他們認爲在這個應用中使用它是個好主意。因此，我有大約170個通過Spring配置的對象（幾乎每個應用都可以看到）。每個簡單的對象都通過標籤連接。當然，一切都是單身，所以添加諸如多文件處理之類的功能幾乎是不可能的。

我可以假設以這種方式使用Spring頗有爭議嗎？我認爲IoC和Spring適合其他需求（比如更改數據庫驅動程序或其他動態配置）。

編輯：此應用程序的GUI有點類似於Visual Studio圖形用戶界面。所以我有選項卡日誌文件（這是一個Spring組件）。我有書籤選項卡（一個Spring組件）。所以，想象一下，對於Visual Studio中的每個選項卡，您都有一個Spring組件。並且每個組件都具有僅能夠與其他單個組件連接的接口。

所以有可能需要文件標籤（配置兩個compoennts）。但這意味着兩個書籤窗口（這沒有任何意義 - 在VS中，每個文件都有一個）。

@Earwicker：幾乎在這個項目中的每一個類是通過Spring（文件加載，文件索引，書籤選項卡，文件標籤，標籤colorizer）配置

來源

2009-06-23 Michal Sznajder

一些代碼示例，爲什麼你不可能實現多個文件處理，將是偉大的。 – IAdapter 2009-06-23 09:29:28

根據你的描述（正如其他人所說），不可能判斷最終設計是好還是壞。

IOC的終極極限如下所示：每個有用的API都被包裝在一個組件類中。該API的參數由其他組件提供。例如，如果應用程序可能需要讀取一個文件，你就會有一個分量（僞）：

public class ReadFile : IStreamFactory 
{ 
    IFilePath _path; 

    public ReadFile(IFilePath path) 
    { 
     _path = path; 
    } 

    // implementing IStreamFactory 
    Stream Get() 
    { 
     return new FileStream(_path.GetPathString()); 
    } 
}

所以現在做能夠在文件打開流的那個對象，你需要寫另一個實現IFilePath的組件。你可以寫幾個：一個存儲常量文件路徑的組件（當然，從配置中讀取！），一個組合兩個文件路徑的組件，一個從另一個組件獲取純文本的組件（實現另一個新接口，ITextSource？），這是一條有效的路徑。

無論如何，你會明白這一點。這幾乎就像是將普通應用程序的每一行一樣，並將該單行放入單獨的組件中。又如：

class IfThenElse : IAction 
{ 
    IBoolean _test; 
    IAction _ifTrue; 
    IAction _ifFalse; 

    // omitting obvious constructor 

    // implementing IAction 
    void Do() 
    { 
     if (_test.GetBool()) 
      _ifTrue.Do(); 
     else 
      _ifFalse.Do(); 
    } 
}

你需要表示「範圍內，哪些變量可以被宣佈爲」其他組件，以及「命名變量聲明」和「引用變量」，它必須以某種方式能夠適用於任何類型的組件。

所以，現在您需要將所有這些微型碎片綁定在一個巨大的XML配置文件中，將它們全部組裝到應用程序中。

如果你已經在儘可能低的水平上做到了這一點，這將是非常荒謬的，因爲編寫XML文件的任務將與以通常方式編寫應用程序相當。除了語法將基於XML，所有函數的名稱將完全不標準，並且調試支持將會很糟糕。

如果你能在上面找到一個「甜蜜點」，那麼你的XML格式可能是用戶喜歡的東西，比底層語言的「原始」編程更容易學習。

來源

2009-06-23 06:47:07

當你說「一切都是單身」你的意思那是在Spring中配置的情況？我不希望類型本身（代碼中）是單例 - 事實上，能夠使用IoC配置事物的一部分是避免真正的單例（例如，使測試變得更加困難）。

我不能真正猜到實現「多文件支持」的最佳方式，您的問題在沒有看到代碼的情況下談論 - 但它肯定不應該太難。有多種方式可以處理它，或者爲適當的組件注入一個工廠，或者讓應用程序讓Spring在需要時創建組件。（後者對Spring的依賴關係更具侵入性，但可能意味着更少的鍋爐代碼。）

很難在不看到它的情況下判斷代碼，但通過大量鬆散耦合的組件創建複雜的應用程序使用Spring配置對我來說聽起來不太糟糕。

來源

2009-06-23 06:23:09

動態配置（如更改數據庫驅動程序或用模擬驅動程序替換圖層進行測試）只是Spring和IoC的許多優點之一。也許主要優勢是完全分離關注點。所有物體彼此獨立，執行特定的任務，集裝箱的責任是將它們連接在一起。

另外在春天，singleton concept與設計模式singleton不同。我會說使用IoC適用於中等或大尺寸的每種應用。也許開發人員對Spring並不是非常有經驗，也沒有使用一些更高級的技術，這些技術真的可以減少代碼的大小併產生更優雅的結果。

來源

2009-06-23 06:28:54 kgiannakakis

-3

在此，我對春天的經歷，我會傾向於去一個架構，只有你知道豆類單身應該是春季管理。其他豆類應該由那些春豆中的代碼管理。嗨，手動。

這樣，彈簧的功能與應用程序的功能有很大的分離。使用spring會變得非常棘手，如果您將它用於上下文中的非單例對象，那麼這很有用，正如您現在所遇到的那樣。

我確實承認這不適用於任何情況，但聽起來它可能適用於您的情況。

來源

2009-06-23 15:50:11

春天是有幫助不妨礙或限制你，但是清理所有的鍋爐板代碼，沒有人願意看到或寫入以及測試/ DB支持等等等等

這是真的，那從技術上來說，可能會換出一個持久性實現，但實際上這很少發生，並且無論你認爲它們多麼不可知，它都會對你的接口產生影響。

使用Spring的一個更好的理由是我已經提到過;測試...

我不關注你的評論關於一切都是單身，如果這種情況確實是你的架構師做出的決定，因爲你可以在Spring中擁有非單例或原型，並且被鼓勵去做所以需要避免看起來程序化或腳本化的貧血域模型和類。

在Spring中使用原型對象肯定不難。

請記住，在所有有光澤的外觀和IoC下，Spring只是一個工廠。

來源

2009-06-26 13:01:27 JamesC

春季錯失示例

回答

相關問題