1樓：正怒月神
首先，使用xml，是為了靈活配置，不用硬編碼。
這個無可厚非嘛。
但是隨著xml配置的越發繁雜。
終於誕生了 springboot，約定大於配置。
正所謂，過猶不及，過剛易折嘛。
2樓：
你配置Nginx不就相當於配置XML嗎？ 還有配置微服務註冊這種場景，你說這種場景我配置個微服務的策略， 請求權重這要寫到程式裡是多麼可怕的一件事，
3樓：李元秋
就說說網頁吧，最開始是純前端渲染；後來為了動態，搞出來服務端渲染，PHP，ASP這種；再後來又回到了純前端渲染，搞出來前後端分離；現在前端界又在喊服務端渲染，要搞同構渲染。
在外行眼裡就是：前端渲染—服務端渲染—前端渲染—服務端渲染...搞前端的真的是吃飽了撐的麼？
4樓：奧陶紀震旦鴉雀
spring最早時我沒接觸過，不過這時jdk還沒1.5呢，所有的bean都需要把全類名寫死在xml裡。
後來spring2時就有了註解掃瞄功能（大概是這個版本？），這時註冊自己的bean就只需要配置包名，而具體的類只需要打上元件註解即可註冊，大大降低了配置量。
我記得spring3時有了配置類的功能，但配置類也並非是硬編碼，只是提供一種更輕便的配置方式而已。
而springboot在去xml這條路上做的事情也並非是註解，而是其他的幾件事情：1是提倡了約定優於配置，通過約定將配置包名的工作也省略了。2是提供了web應用的入口類，可以將專案層的一些配置通過入口類的註解進行配置了。
這樣一來原本大量繁瑣的配置工作已經被降低到很少的程度了，且很多繁瑣的配置選項都有了約定好的方案。剩餘的配置量則完全可以用更輕便的方式進行配置了（yaml、入口類、配置類），這時去掉xml自然是合理的選擇。
所以能看得出來並非是配置這條路錯了，哪怕是現在我們也要進行許多輕量級的配置。只不過是我們配置的工作量大幅度降低了，於是也就不再需要xml這麼重的配置方案了。
5樓：格魯特大魔王
因為實際上,為了所謂 "擴充套件性" 而搞出來的那套東西 99%都是過度設計。
一旦碰到需求變更, 大概率單純改xml是無法完成任務的。費那個勁還不如去硬編碼
XML的確是個好東西, 但是不應該被如此的當成配置檔案而使用, 比如去用來做view層的模板是極好的
6樓：海淀遊民
用XML做配置本意是為了製作各種開發輔助工具來提高開發效率，因為XML規範容易編寫工具去處理嘛。但現實是那些工具往往做的BUG遍體而且還挺難學，最後逼得大家就都去手寫，例如安卓的布局XML手寫的特別多。這哪受得了，於是各種「投機取巧」的例如註解方式就流行起來了。
所以說乙個技術好不好學是硬道理，那些把自己都轉暈了的最後就只剩下幾個自以為看懂的在吹噓並一副世人皆醉我獨醒的樣子。
7樓：
當初寫xml是因為xml配置繁瑣，容易出錯。所以出現了註解，perproties，yaml，配置類的做法。然而部分xml已經可以通過外掛程式自動生成了。
相比xml。註解過於簡單，寫配置類其實也很繁瑣。perproties和yaml可以看做是簡單的xml。但是靈活性上明顯不如xml，僅僅能做到賦值。
8樓：jun ling
一開始這個xml是協議(是百人眾給銀行那些傻大黑粗的機器設計的)後來架不住這些人用來寫配置.
再後來有一些智商爆雕的人用做給程式和人之間寫協議.(嗶..此處省略...
)這放在當時的場景裡面是可以理解的,你想想啊,乙個百人眾領導的開發團隊,甲方某個地方要改一下,或者臨時使用另一種協議.這個研發,測試,驗收,部署的流程特別消耗成本.
至於這個東西為什麼現在還在用,因為他們會(...@
9樓：逗泥丸的平方
註解一時爽，xml還是簡單。
開發過程中:
就算很煩，xml的讀不懂，是花時間可以理解的。
註解要是搞錯了，那就尷尬了。比如兩類不同的字段(或者field)錯誤的使用了同樣的註解進行標記，可能你修改的時候就需要去爬一下……如果超出預期設計甚至需要改變很多東西，甚至讓註解產生新的語義。
經典運維:
xml(配置檔案)當年重要的優勢在於不需要編譯，如果生產問題，甚至可能在現場進行修改(打死)
再就是，註解形成一種約定的時候會比較好用，如果自定義註解，加上「經典」的注釋和命名……
xml爛乙個，註解爛一窩。這並不是因為它們的特性決定的，而是它們的潛力(方便程度)決定的。
spring的註解的確方便了開發，但是真正有多少人是按照他推薦的方式使用呢，很多說明我也懶得看，專案都是能跑起來就得過且過了。比如經典的autowired和resource
10樓：據說他姓feng
因為這群用 Extended Markup Language 的人，真的把XML當Language來用。
然而XML又沒有XMLVM，而需要各門Language去按照Language那樣去解析它。
既想要Markup的簡單，又想要Language的靈活。實際上既沒有Markup的簡單純粹，又沒有Language的邏輯性和靈活性。
掌握這門Language的難度，已經顯著高於直接用其他Language去表達邏輯的難度。
對比之下，HTML就安分守己很多，從沒有誰認為HTML是一門正經的Language……只知道，這玩意是寫網頁的，多好
11樓：煜王
Xml的話。有利於分離，但是數量配置多了，就成了負擔，而且專案大了，靠配置也就特別多和繁瑣，另外還沒有相應的檢查。所以現在就成了約定大於配置。
12樓：Lewis Berly
過去硬體貴人工便宜，開發思維是大平台N合一，需要一種結構把鬆散的、可插拔可替換的模組模組組織起來，xml是一種不算太壞的組織形式。
現在硬體便宜了，思路切換成了高可用、分布式、微服務，功能專一的小服務需要的是短平快且邏輯簡明，xml就過時了。
13樓：Ken
個人感覺配置由以前簡單的通過XML方式定義，變成了由註解+配置檔案定義結合的兩種方式，對於類與類、類與介面、引數與引數配置對應屬性名稱等成為使用註解定義的關鍵資訊，類似於資料庫的META資訊。這一部分資訊確實也會發生變化，涉及到修改時是需要進行重新編譯的，但是相對來說比較穩定固定，就算以前定義在XML中，如果涉及到修改大多數情況也是需要進行原始檔修改的，也是需要重新編譯的。
而現在的配置檔案逐漸變成了純粹的引數屬性的定義，包括資料庫鏈結、資料庫使用者名稱等等，保證了原來最容易變化內容的可擴充套件性。
java EE和那些框架對Java程式設計師來說是阻礙還是幫助？
路人 個人理解，框架是前人作出的幫助你提高效率，使得工作更加方便的一種方式，在你能熟練運用它的就是幫助，但是在你不能很好的使用它的時候，那就是阻礙了。框架是一種更高層次的東西，不是基礎也不是必須，覺得是阻礙不用就好了。 個人經歷 各種設計模式，先在框架裡體會到爽了才會去主動學習。好的框架說不上毒害，...
為什麼Go的web框架速度還不如Java？
Function Go為高併發而生從語言級別支援併發，通過 Goroutine 協程來實現程式併發執行，協程是使用者態的輕量級執行緒，Goroutine的排程完全由使用者控制。Goroutine 上下文切換只涉及到PC SP DX三個暫存器值的修改 而執行緒的上下文切換則需要涉及模式切換。Gorou...
你曾經為寫作瘋狂的什麼程度？
Miracle 藍 最近工作不是特別的忙，感覺心裡特別的空，索性買了10本書，去閱讀，然後每天將近的輸出，已經堅持了一周，感覺滿滿的，真的懂得了，自己感悟的才屬於自己的，你想要的時間都會給你，你付出的，得到的還是成正比的。加油吧 gambler 初中的時候最瘋，可能也是因為無知，所以什麼都敢說且敢寫...