如何處理怪異的Struts操作？

我使用Struts 1.2.4繼承了這個巨大的傳統Java Web應用程序。我有一個關於行動的具體問題。大多數頁面只有一個Action，而processExecute（）方法是可怕的怪物（基於請求參數的嵌套if語句很長很長）。如何處理怪異的Struts操作？

鑑於Actions是命令模式的實現，我正在考慮將這些Actions分解爲每個用戶手勢的一個Action。這將是一個大型的重構，但我想知道：

這是正確的方向？
有沒有一個我可以採取的中間步驟，一個處理單片動作內部混亂的模式？也許Action中有另一個命令模式？

來源

2008-10-16 thvo

我處理這個問題的方法是：

不這樣做「一次一切」
，只要你改變什麼，把它比你發現它
- 更換條件語句與單獨的行動實施是一步。
- 更重要的是：讓你實現從Action類分開，這樣就可以使用它，當你改變框架
- 讓您的新命令實現絕對沒有將Struts參考，使用圍繞這些實施新的行動爲包裝。
- 您可能需要爲您的Struts ActionForms提供接口，以便在不復制所有數據的情況下傳遞它們。在另一方面 - 你可能想繞過其他物體比通常是一串字符串的ActionForm（見您的其他問題有關Struts 1.2 ActionForms）
開始遷移部分新&更好的技術。 Struts 1.2出現後非常棒，但絕對不是你想要在永恆中支持的東西。現在有幾代更好的框架。

肯定有更多的 - 對不起，我的時間不多了這裏...

來源

2008-10-16 18:19:28

棘手的問題，但典型的早期的Web應用程序的開發。首先，首先需要開始思考哪個邏輯構成業務行爲，哪個邏輯構成「流」（即用戶看到的內容），以及哪個邏輯獲取他所看到的內容。

您不必走下工廠和界面的路線，追溯實現遠沒有那麼有用......但將業務邏輯和數據檢索邏輯合併到某種委託中......並留下struts動作以基於該邏輯的成功/失敗來確定頁面流。

從那裏，你只需要花費幾個星期，磨出來

來源

2008-10-16 18:26:49

一層長的方法是從來沒有好，除非它是一個switch語句，其中病例非常短（標號解析或類似的東西那）。

您至少可以將長方法重構爲具有描述性名稱的較小方法。

如果可能的話，您可以通過檢查表單來確認它應該做什麼，然後如果/其他方式通過各種選項來開始您的方法。儘管沒有嵌套ifs，但這些會使代碼無法讀取。只是

enum Operation { 
    ADD, DELETE; 
} 

... 

Operation operation = determineOperation(form); 
if (operation == Operation.DELETE) { 
    doDelete(form); 
} else if (operation == Operation.ADD) { 
    doAdd(form); 
}

如果你能走那麼遠，你有你的邏輯非常乾淨，你可以做任何你想要的重構。

難的部分是讓你的邏輯清晰，並且你可以一步步完成。不要選擇一種模式，直到你明白你的問題是什麼。

來源

2008-10-16 18:34:39 extraneon

如果您打算重構代碼，您應該確保先編寫現有代碼的測試，以確保您在開始重構後仍未更改其功能。

來源

2008-10-16 18:45:45

我要說pshah。作者指出，這些方法非常長，並且具有很高的圈複雜度。這種代碼通常是單元測試的噩夢。 – JonMR 2010-02-22 21:57:01

我已經處理過這種類型的事情。一個好的第一步是將另一個基類插入Action和其中一個原始可怕動作類（讓我們稱之爲ClassA）之間的繼承鏈中。尤其是如果你沒有時間一次做所有事情。然後，您可以開始將功能塊分解爲更小的並行Action類（ClassB，ClassC）。原始ClassA和新重構類之間的任何常見事物都可以被拉入新的基類中。所以層次結構現在看起來像這樣：

Original Hierarchy:  New Hierarchy: 

    Action     Action 
     |      | 
     |      BaseA 
    (old)ClassA     | 
         +--------+----------+ 
         |  |   | 
        ClassB (new)ClassA ClassC

來源

2008-10-17 01:59:26

閱讀我的上面的答案，瞭解有關操作層次結構的想法。我認爲在很多地方這樣做，他們可能在他們的Web層中有太多的業務邏輯。 – bpapa 2008-10-17 22:54:36

Struts在我看來，Action應該沒有太多的代碼。他們應該直接與請求和響應進行交互 - 從表單或請求參數獲取一些數據，將這些信息交給服務層，然後將一些內容放入Response對象中，或者可以在用戶會話中保存一些數據。

我建議遠離繼承與行動類繼承。這聽起來像是一個好主意，但我認爲遲早你會意識到，你實際上比實際使代碼基礎健壯。 Struts具有足夠的基本操作，如果您正在創建新的基本操作，那麼您可能在Web層中獲得了不應該在其中的代碼。

這只是我個人的經驗。

來源

2008-10-17 02:57:43 bpapa

去一次一個
記錄一些測試情況下，您可以稍後回放方法。 Example here（請確保儘可能多地通過代碼，即可以在頁面上調用此操作的所有用戶手勢）
重構該方法，通過創建更小的方法來減少其複雜性。
重新運行測試，你這樣做

在這一點上，你已經重構了大巨大惱人的方法的版本。現在您實際上可以開始創建特定的操作。

您可以使用新重構的類作爲基類，並使用重構的小方法將每個特定操作作爲子類實現。

完成此操作後，您應該對類之間共享的邏輯有一個很好的瞭解，並可根據需要上拉或下推這些方法。

這並不好玩，但如果你將在代碼庫上工作一段時間，它會爲你節省時間和頭痛。

來源

2008-10-17 16:21:35 davetron5000

如何處理怪異的Struts操作？

回答

相關問題