涉及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目录下
框架应该是开放的,可以允许各种其他技术在框架描述的运行上下文中充当自己的组件。同时框架应该也是封闭的,属于这个框架的组件是在这个框架定义的标准中完成的,是他约束着所有开发人员。