初衷是希望有一個簡便，不需要配置文件的辦法，提高數據層的事務處理能力。以及對連接池的支持。
解決思路是通過修改Spring框架，修改BeanFactory的類搜索機制，默認載入相應的類。
并采用繼承的方式，在基類中提供默認方法，允許Spring注入在對象實例中。然后再對象實例中調用。
最近項目組要求使用普元EOS進行項目開發，使用了兩個月左右，雖然說有一些心得（這個以后會寫出來），但更多是看到了不足的地方，在這里就討論一下一個成熟的應用框架到底應該有哪些因素。
底層技術：
Application Framework（下稱應用框架）是為解決問題而生的，無論是基于JAVA、C++、Ruby等等語言，都必須有基礎技術的支持。如JAVA就有經典的Struts+Spring+Hibernate的組合，因此，一個成熟的應用框架，必須擁有完善的MVC框架，以及完整的業務組件管理容器，還有一個成熟的數據訪問框架。這個是一切的基礎。
權限管理：
擁有一個成熟基礎權限架構能夠為應用框架增色不少。如果能夠和框架本身更好地融合，這樣更好。其實目前有很多實現是俄可以借鑒的，如：ACEGI和Spring。
UI：
標簽已經非常流行，擁有完善的標簽庫是必不可少的，Struts是個很好的典范。
Ajax大行其道，如果沒有整合一些方便易用的AJAX控件，估計也算不上是一個好框架。
另外還有類似于Freemarker、Velocity之類的簡化UI開發的好東東，整合一兩個，對于減少開發、提高維護性有很大幫助。
開發工具：
提供敏捷快速的開發工具是一個成熟應用框架所不可或缺的。使用一個成熟的應用框架的開發工具進行開發，可以讓開發者最大程度減少對于技術上的瓶頸，讓開發者很輕松就可以完成高質量的代碼，剩下的精力可以用于專注于業務等其它方面。
另外還有像：單元測試、應用部署等等方面，都是必不可少的一部分。（PS：我是非常痛恨維護幾百行ANT的build.xml代碼的人）
這里不得不稱贊一下普元，普元提供的開發環境和它自身的底層技術融合的非常好，對于開發者而言，是非常方便的，可以不需要很多的培訓就可以使用IDE開發出完整的應用。而且測試和部署都很方便。
代碼生成器：
其實這個應該和開發工具放在一起，但是因為比較重要，所以單獨提出來說。
一個好的代碼生成器可以省去開發人員很多不必要的麻煩，能夠非常大地提高開發效率。普元的代碼生成器是個不錯的典范。
我們公司自己也有一個JOP的應用框架，但非常簡陋，和普元的設計思想不可同日而語。呵呵～～有點扯遠了，但能夠看得出，代碼生成器對于應用框架是必不可少的。
協同開發：
整合一個好的協同開發和版本管理工具，能夠最大程度地降低溝通成本。除了能夠支持類似SVN或VSS之類的代碼版本管理工具之外，還應該融合進類似Visual Studio Team的任務管理和缺陷管理工具。最好擁有一個可以進行自我積累的知識庫的實現。WIKI是個不錯的主意。
設計器：
我提出這個是因為看到了IBM的RUP，擁有一個能夠從設計到代碼實現乃至后面的測試這樣一個全流程開發工具，一直是IT人員的一個美好夢想。
一個好的設計器，可以很輕松地在設計圖和代碼之間相互轉換，對于需求變更，設計管理、甚至項目后期的文檔都有很重要的意義。
這里又要提到普元，普元在這方面很聰明，走了一條不同的路，它把代碼變成一個個圖標時，本身就實現了對于設計圖和代碼之間互轉關系。（當然，實現的方式有點土，而且沒有辦法支持標準的UML）
運行容器：
大家可能覺得奇怪，容器為什么要單獨提出來說，很多JAVA開發者都會說，只有遵循JAVA標準就可以啦～。其實不然，一個成熟的應用框架當然要考慮其兼容性，但是有時候，過多考慮兼容性往往會犧牲效率。事實上，很多應用框架被開發出來，都是有一定的局限性的使用場景，針對使用場景的環境進行優化，絕對比使用通用的方法效率要高的多。如我們公司的移動項目使用的是WebSphere，我們的框架就有一個針對WebSphere優化的版本，但同時也存在一個通用版本。
當然還有其它方面也可以引用這種思路，比如使用Oracle自帶的一些JDBC類，其效率就比使用JAVA標準的JDBC類要高得多。
其實應用框架被創造出來的目的就是快速、高效、低成本地解決問題，這個大家都知道，但是何謂“成熟”，估計100個人應該有100個答案，這里我的理解就是開發快捷、較低的學習成本、運行穩定，就是一個成熟的應用框架。
PS：上面好像說了一些不少普元的好話，大家千萬不要以為我是普元的“托”，晚點我再寫遍罵它的文章吧～～呵呵～～。其實我更喜歡SpringSide，但是除了“底層技術”這塊之外，在其它方面還有很長的路要走，希望江南白衣兄能夠堅持下去。