首先spring给了我们java开发工作者的一个新的思路和可行的技术解决方案。
IOC其实简化了项目开发的部分难度以及给与我们一套和J2EE传统规范略为不同却比较可行的解决方案。hibernate以及其它数据库中间件工具,也使得项目的底层接口维护成本以及开发体验有了一些突破。
但是,spring、hibernate等作为一个开源项目,没有从根本上给与我们一整套解决方法,而且还造成了架构之间的重叠和冲突。此外还有很多限制,更多的来自于JCP固有的缺陷。相应的Hibernate等ORM还具有很多这样那样的问题。
使用框架,但是尽量减少框架的依赖程度,是我的一些经验和建议,但是除非性能需要少用JDBC,多走回头路没有什么好处,很多人吃过的苦,没有必要再吃。
业务逻辑层和表示层分离其实为了维护的方便性,因为固有技术的历史原因,如struts广泛使用。所以给我们分离造成了很大的问题,这些结果,原因很多。 可能Web容器的标准给我们带来的一个非常大的灾难,让我们以非application开发思路去解决这些web程序开发。
也许我们从一开始就走错了。
ajax,虽然是一个绚丽的新星,但是仅仅是流星罢了。或者你可以偶尔使用它的一些余热来点缀你的应用。
web service , 系统集成主力军,没什么好说的,该用的人都在用。
虽然我看好 Echo2 这种模式,也许是一个划时代的理念,但是,很可惜,他不是Microsoft的产品,没有强大的财力支撑,注定发展艰难,期待奇迹。
虽然说得很散,但是也是一些平时经验的拾遗,也有些困扰我的问题,相信也有很多像我一样的人在思考这些问题。
IOC其实简化了项目开发的部分难度以及给与我们一套和J2EE传统规范略为不同却比较可行的解决方案。hibernate以及其它数据库中间件工具,也使得项目的底层接口维护成本以及开发体验有了一些突破。
但是,spring、hibernate等作为一个开源项目,没有从根本上给与我们一整套解决方法,而且还造成了架构之间的重叠和冲突。此外还有很多限制,更多的来自于JCP固有的缺陷。相应的Hibernate等ORM还具有很多这样那样的问题。
使用框架,但是尽量减少框架的依赖程度,是我的一些经验和建议,但是除非性能需要少用JDBC,多走回头路没有什么好处,很多人吃过的苦,没有必要再吃。
业务逻辑层和表示层分离其实为了维护的方便性,因为固有技术的历史原因,如struts广泛使用。所以给我们分离造成了很大的问题,这些结果,原因很多。 可能Web容器的标准给我们带来的一个非常大的灾难,让我们以非application开发思路去解决这些web程序开发。
也许我们从一开始就走错了。
ajax,虽然是一个绚丽的新星,但是仅仅是流星罢了。或者你可以偶尔使用它的一些余热来点缀你的应用。
web service , 系统集成主力军,没什么好说的,该用的人都在用。
虽然我看好 Echo2 这种模式,也许是一个划时代的理念,但是,很可惜,他不是Microsoft的产品,没有强大的财力支撑,注定发展艰难,期待奇迹。
虽然说得很散,但是也是一些平时经验的拾遗,也有些困扰我的问题,相信也有很多像我一样的人在思考这些问题。