初衷是希望有一个简便，不需要配置文件的办法，提高数据层的事务处理能力。以及对连接池的支持。
解决思路是通过修改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，但是除了“底层技术”这块之外，在其它方面还有很长的路要走，希望江南白衣兄能够坚持下去。