对于一个软件公司而言，在做项目或产品的过程中，为何要应用一定的技术框架呢？相信有一定规模一定历史积淀的软件公司里，都存在着自己特有的技术框架，我们应用框架开发无外乎是本着提高代码的重用性、降低开发应用模块的技术难度，增强软件的维护性，进尔达到提高工作效率、降低生产成本的目的。这也是技术框架存在的根本和意义所在。

本人是个对技术的推崇者或者说是有些图腾崇拜的人，从学习和使用 java 的第一天开始，就对这种纯粹的面向对象的编程语言产生了浓厚的兴趣，从早期秉烛夜读《 java 编程思想》、《 java 核心技术卷 I 、卷 II 》到《 J2EE 设计与模式》。。。《深入浅出 Hibernate 》。。。《 Spring in Action 》等，切身感受到当今主流 java 应用技术的发展，也很感谢前辈们为大家开创了应用技术之先河，为我辈指明了发展的方向和前进的道路。

在当今技术潮流日新月异的时代各种各样的技术框架林林总总，很难去评价个中孰优孰劣，个人觉得在项目开发过程中最适合的框架就是最好的，以项目的规模和特点来决定对技术框架的选型。现就个人对于框架的开发的一些体会和大家一起交流一下，前端采用类 Struts 模式做 MVC, 我觉得 MVC 的精华所在就在于请求的汇集和请求的分发，采用 filter+mainservlet 的方式，在 filter 类中可以进行对各种请求的约束和限制处理，同时可以进行对请求合法性的判定和校验，也可以实现达到负载均衡的处理，也可以根据实际的项目需要设置多个 filter 类进行分类过滤。通过 filter 类的合法的请求全部由统一的 mainservlet 主控器接口进行分发处理，在这里可以添加对线程的约束和控制，以保证所有请求可以顺利的分发。业务逻辑层采用 Action+BPO 的模式， Action 作为动作的描述， BPO 作为对于动作进行响应的业务逻辑处理。持久层部分采用 Hibernate 和 DAO+VO 两种模式并存的方式，持久层部分之所以采用两种模式处理，主要是考虑到业务逻辑的复杂度，对于多表及连和复杂的业务查询处理，感觉配置 Hibernate 文件也相当的复杂（也许是本人应用 Hibernate 的深度还不够，对 HQL 语言的认识还比较肤浅），因而还采取传统的 jdbc 访问模式来处理。事务处理用 Spring 框架来进行处理。在表示层的 jsp 中只进行 tag 的属性设置和 java 的表达式的输出，所有的 java 逻辑代码全部用 tag 来进行封装。有兴趣的朋友可以发 e-mail 给我，来进行此框架的交流 E-mail:syangsheep@163.com, 同时也欢迎大家拿出自己应用的框架来一起进行交流和探讨。