我最近實現了一對相似大小的Web應用程序，其中一個使用了「框架」，其中一個我編碼自己，但使用了一組現有（主要是開源）庫來提供某些通用功能，我否則會使用框架。應用程序框架是一種反模式嗎？
我注意到以下幾點：
從這個人的經驗，我得到的印象是，使用框架可能被視爲長期應用的可維護性反模式。
這是真的嗎？
我認爲這是非常主觀的。在我看來，應用程序框架確實是一種反模式，特別是對於更大，更復雜的項目。我認爲有兩個原因。
我看到的框架最大的問題是，通過使用框架，你放棄了控制。 JB Nizet寫道：「沒有人強迫你爲應用程序的每個部分使用框架」，這很好，但不幸的是它通常不是。通常框架有控制權，你有你的回調或派生類，當你想做一些特別的事情時，你不能。
這會變得更糟，因爲一般來說，要很好地設計框架是非常困難的。框架越差越受限制，框架用戶越多。我見過的很多框架都有一些基本限制，最終限制最終應用程序的方式。我不會說只有框架創建者纔會責怪，嘗試創建一個不限制框架用戶的框架，這只是一個非常困難的，如果不是不可能的任務。儘管如此，框架並不是全部不好。如果您的項目符合框架並且不會超出框架，那麼框架的確會加快開發速度。應用程序中的小型框架在處理一個問題域時通常也會簡化，通常沒有太多的風險。但是，在最終的框架中，一方面增加您可能不需要的複雜性，另一方面將界面與引擎耦合，限制框架用戶。
不，事實並非如此。有很好的框架和糟糕的框架，並且有適合您正在開發的應用程序的框架以及不適合此應用程序的框架。你只需爲工作挑選最好的工具。不預期應用程序的複雜性不一定是框架的錯。這可能是你的，因爲你只是沒有選擇適當的任務框架。
無論選擇的框架是什麼，沒有人強迫您將它用於應用程序的每個部分。如果框架能夠簡化90％的應用程序的開發，並且在10％左右的時候使其過於複雜，那麼就不要爲這10％使用框架。
我不認爲模式/反模式術語是非常有用的 - 它說的形容詞「好」和「壞」差不多。但我認爲大多數框架都有嚴重的缺點。
首先，讓我們定義一個框架是什麼：
如果一個框架是一個人，它的座右銘可能是「不要打電話給我們，我們會打電話給你。」
根據定義，你不得不以符合框架的風格編寫代碼，而不是以適合應用程序的風格編寫代碼。除非這兩種風格一致，否則已經存在明顯的問題。
一個框架最初可能會考慮到一個特定的問題，而許多框架在解決這個問題上相當成功。然而，一旦最初的問題得到解決，大多數框架往往會不斷髮展，包含越來越多的功能，這些功能只與最初的問題模糊不清。
看到一個web框架並不少見，它也可以做安全性，調整圖像大小，提供控制反轉或與數據庫交互。該框架已經失去了重點，並試圖成爲每個人的一切。現在既不方便也不高效，可能由於缺乏重點而出現問題和不完整。
然後，你最好用圖書館做一件事，做得很好。
無論是從頭開始還是使用庫，編碼的行爲都是創建框架的行爲。我看到包括我自己在內的開發人員嘗試在沒有框架的情況下編寫應用程序，我們得到了什麼？一個框架 - 只針對該應用程序。沒有應用程序存在未定義其組成代碼的結構。沒有像非框架這樣的東西。模式必須找到代碼的方式，不管它是你編寫的代碼還是代碼重用。我厭倦了聽到那些拒絕使用好框架的崇高開發人員的陳詞濫調，因爲他比其他低級開發人員更聰明，他可以在沒有人的情況下編寫應用程序。他就像是理論物理學家爲獲得諾貝爾獎所做的努力一樣，他花費所有時間撰寫方程和假設理論，但他不會因多年的勞動力收集數據和做出實際證明或反證所需的艱苦觀察而煩惱。這是虛僞。
這就是我原先想的，但是這不是預先假設應用程序的範圍/複雜性是事先知道的，以便選擇正確的框架，至少達到90％的水平？在我的經驗中，你很少有這種保證的奢侈品...... – mikera
@mikera - 我會第二次認爲有好的和壞的框架，好壞是相對於你的應用。如果您懷疑您的應用將來可能需要一些奇怪的功能，那麼選擇不會干擾的框架是您的責任。只需在防守方面選擇你的工具，這就是它的全部（我認爲）。 – cji