我在一家爲我們的產品使用Ext-JS的公司工作。目前，該產品擴展了Ext-JS組件並覆蓋了父功能。這至少使升級變得困難。我們保留了Ext-JS，但正在考慮以非混雜的方式使用它。似乎有兩個陣營。在一個陣營中，成員們認爲我們應該在Ext-JS之上寫一個抽象，以便我們決定在幾年內改變框架，希望我們不那麼被鎖定。我個人認爲這是一個愚蠢的目標，所以我坐在營地第二。我的推理是Ext-JS團隊花時間爲網絡提供了一個合理的抽象 - 他們在解決這個問題的領域，而我們只是試圖實現一個很酷的產品。我認爲如果我們寫一個抽象的話，它會假設Ext-JS。我看到我們寫的低級抽象功能不那麼強大，並且不會映射到jQuery世界（或任何其他框架）。關於正確的行動方案的意見？如何在野外使用Ext-JS？摘要走了還是不走？
我同意你的意見;我認爲這是一個愚蠢的目標。原因如下：
最後（幾年後），您可能不會更改框架。如果你不這樣做，那麼你花費了額外的時間和資源，增加了一層抽象，不會給你買任何東西。它不僅無法完成您設定的目標（使您的選項多樣化），而且會增加您和您的隊友需要維護的代碼量。
您可以隨時使用其他Javascript庫對項目進行模塊化，以滿足ExtJs無法滿足的任何需求。例如，如果你不喜歡ExtJs的圖表實現，那麼你可以包含jQuery並使用像jqPlot這樣的插件。
要編寫適用於當前和未來庫的抽象將很困難。你怎麼能保證你的抽象能夠抵抗當前庫選擇（ExtJs等）或未來任何未來JS庫的變化。
只是想一想幾點。總的來說，我認爲這將是一個負擔，所以我會選擇一個滿足大部分需求的多元化圖書館，然後在必要時添加更小的圖書館。
我認爲選項2是更好的選擇。如果你建立了一個偉大的網絡應用程序，並且它運行得非常好，那麼你實際改變到一個新框架的可能性有多大？
ExtJS旨在進行擴展。我肯定會推薦使用Ext.extend（）和Ext.override（）來做擴展。當你升級到更新版本的Ext時，使用這種方法來完成你的重寫，你真的不應該有那麼多困難。
在ExtJS之上構建一個額外的抽象層看起來像是一個非選項。這需要公平地分擔工作，可能很難做到這一點（因此，切換底層框架非常容易），而且可能不需要它。
擴展現有的ExtJS並不差，但您需要以結構化和可控的方式來實現。不要過分 - 只在需要時擴展 - 並將擴展放置並打包爲單獨的文件和結構，以便輕鬆找到X和Y類的擴展。嘗試提出可重用的解決方案，以便您每次需要在某處進行一些修改時，不需要編寫新的擴展。
如果你確實在Ext之上構建了一個真正的抽象層，你應該出售它或者開源它。這似乎相當於構建可以在使用NHibernate，EF和iBATIS之間無縫切換的DAL。 – 2011-03-17 13:02:45