據我所知，有對註解的控制器兩大好處春：爲什麼Spring註釋控制器更適合傳統映射？
這似乎帶來兩個主要的缺點，但是：
儘管我個人認爲上述缺點超過了好處，但註釋的使用似乎是首選。這給我帶來了這樣的問題：爲什麼Spring註釋控制器更適合傳統映射？
編輯至於耦合：
我意識到，在這兩種情況下有一定的耦合與所涉及的基本框架。 Spring所需的接口由一個單一的方法組成，並且可以大部分被抽象出來（例如，interface MyController extends SpringController）。另一方面，註釋除了特定於框架之外，還需要在每個文件中引入大量的導入。
我不認爲單個文件更容易維護。我發現的一個很大的註解允許你在比項目更多的地方使用對象，並且他們帶着他們的配置。我不必編輯源代碼，然後記住每個使用它並修復其配置文件的項目。它創造了一種更加模塊化的思維和發展方式。
聯軸器鬆動。註釋類不依賴於父類方法或接口，並且可以封裝在符合任何框架的類中，稍後您應選擇遷移。您仍然需要刪除大多數編譯器的註釋，但代碼和邏輯不需要更改，只需要以與Spring @ MVC類似的方式提供參數和調用流程即可。
這取決於維護的類型和規模，不管其中一個是否比另一個更具破壞性。如果您需要更改多個實體的配置，那麼通過註釋配置中的各種java文件進行篩選會更加惱人。而如果你在重構控制器和URL改變，那麼在java類中做這件事將比編輯一個單獨的xml文件（包含許多不適用於所做更改的行）更具破壞性。
有幾個額外的好處：
在單個控制器類的幾個動作的邏輯分組（儘管它也可以與MultiActionController，但不那麼靈活）的
簡化單元測試，因爲在大多數情況下，您可以傳遞簡單的參數，並且不需要準備模擬HttpServletRequest/HttpServletResponse s。
與@RequestParam,@PathVariable等映射的額外靈活性（雖然它可以在傳統的控制器中實現，但由於傳統控制器的靜態性質，我認爲它不如註釋那麼優雅）。
另外我不能同意第一個缺點 - 在我看來，註釋引入的耦合比繼承要少得多。例如，甚至可以使用編譯後的註釋控制器作爲常規類，而無需在類路徑中使用Spring（儘管註釋源代碼的編譯仍需要構建路徑中的註釋）。
讓我的缺點爭辯：
事實並非如此。這是元數據，可以輕鬆消失而不影響功能。另一方面，如果不得不擴展某些類並使用它們的方法，那麼以後就不可能擺脫框架。
這是一樣的。我已經使用了兩種方法，但都不好。利用現代IDE搜索功能以及適當的命名約定，沒有單個配置文件就簡單了。
除了現有的答案，我覺得這是值得一提的是，Spring MVC中有映射處理適配器處理器之間清晰的分離，以及。
前者使然其中處理程序被調用對於給定的請求，後者確定如何該處理程序被調用。
一個極端，你有「經典的」Spring MVC，映射定義在XML中，而適配器由舊式Controller類層次結構定義。在另一個極端，你有@Controller和@RequestMapping，一切都在註釋中定義。
但是，混合搭配是完全可以接受的。例如，您可以用XML定義URL映射，「舊樣式」，但仍使用@Controller -annotated處理程序類。通過這種方式，您可以避免將URL映射放入註釋中（這並不總是一件好事），從而保留註釋的極大改進的類簽名靈活性（並減少對Spring API的依賴）。
這種混合方法的能力意味着您幾乎可以定義最適合您的方法。
對我來說更好的一個問題是「爲什麼SpringSource只在其ref參考手冊中記錄註釋方法？」。他們刪除了XML風格的MVC配置文檔，我覺得很煩人。 – skaffman 2011-01-05 17:24:58
@skaffman是的，這是春季參考的最佳部分之一：[Classic Spring MVC]（http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/classic -spring.html＃clasic-spring-mvc）:-) – 2011-01-05 17:30:39
@Sean：Bah。失敗。 – skaffman 2011-01-05 17:31:42