涉及java的软件开发，首先想到技术框架，涉及后端的技术框架，首先想到了SSH或者SSI等。他们的组合，已经成为了事实上的标准，也确实能够很方便的解决很多问题，虽然可能并非最适合你的。
技术都是为解决具体业务而生的，凡技术框架也是为了解决程序猿的业务问题而生的。本文讨论下我们都需要怎样的技术框架。
我是一个懒人，总是想有一个超牛逼的技术框架，技术框架能做很多事情，转而在做具体业务的时候，只需要关注业务，其他的代码都是能够通过工具生成、配置、运营管理等自己满足，这个就是我第一次写框架的目的。使用SSH框架，在上面做了一个超级牛叉的taglib以及Spring、BusinessObject等的类或者抽象类，然后做了一个基于awt的代码生成工具，开发过程：先建表，注释和表的主键、外键全部建好。然后使用代码生成工具生成代码和配置（那时Spring、Hibernate还没有注解）以及描述界面的元数据，瞬间一个对象的增删改查的功能都有了，这个就是我最初想要的。然而随着项目的进展，我碰到一系列的问题：
1、启动时间太长，每次启动都需要超过90秒，虽说机器可能不够好，但是这台机器启动裸Tomcat只需要6秒钟呢。
2、如果数据库表有修改，意味着ValueObject、hbm.xml、等一系列的文件需要修改，真是烦透心了。
3、所有业务代码都从框架中继承而来，包括BO必须有id这个属性，嵌入太深了。
我花费了巨大精力的第一个框架，在我使用过一次后，我再也不想使用了。
但是通过这次框架的演练，我知道了一个框架最终需要具备的东西：
1、一套严格上下文描述的运行环境，例如Spring等；
2、一套严谨的在上下文中运行的各负其责的组件/公共组件库；
3、一套约束开发人员的标准；
4、一套标准的接口规范，让所有的系统成为服务的提供者；
5、还有一堆公共工具，这些是经年累月积累下来的，多数存放在utils目录或者common目录下
框架应该是开放的，可以允许各种其他技术在框架描述的运行上下文中充当自己的组件。同时框架应该也是封闭的，属于这个框架的组件是在这个框架定义的标准中完成的，是他约束着所有开发人员。