[原创]浅谈框架与设计模式

[watermark]    当今的Java时代是框架当道的时代，struts、spring 、hibernate、JSF、webwork、JDO等等，正如春秋战国的诸子百家，百花齐鸣、百家争放。
    我在做项目的时候接触了一些框架，掌握精通我不敢自夸，第一次做struts的时候记得是照着孙卫琴姐姐的书来照搬的，第一次学struts也觉得很吃力。通过几个框架的学习以及设计模式的学习，我越来越觉得重要的不是框架而是设计模式，也许一个优秀的框架也会随着时间的流逝而淘汰，但思想才是永远不变的。一个优秀的框架到处是设计者的思想以及使用的设计模式，比如hibernate主要的思想是ORM，学会了ORM思想，再学其他数据层的框架基本上就是修改下配置。
    如果能根据项目来设计出符合该项目的框架，比如一个很大的项目并不适合用spring，但是可以用spring的IoC思想来设计逻辑层，这才是真正的系统架构。就好像手中无剑，但心中有剑。
[/watermark]

最小侵入,解耦合,他们确实在某些地方很有用处,甚至在脱离了java 之后,依然可以用于其他地方.关键就是一种由实际开发经验总结出来的思想.
但是偶对这些东东说实话个人不是很感兴趣.
想起我现在不能用我以前学的一点东西就伤心...

时间久了才会体会到框架的便捷之处，毕竟一个开源的框架可以包括一般项目应用所能遇到的大部分问题。而且一个通过检验的框架会有大量的实例和文本资料，对于学习使用也有很大的帮助。如果使用比较冷门的框架，除非开发部门的人都对此有所了解，否则在后续开发工作中反而会迟滞开发进度。
目前工作中使用到一个早期持久层框架，连相关资料都找不到，实在是不方便理解。项目没有采取目前流行的struts+spring+hibernate，用流行的框架可以有大量资料可以查询和相关范例可以参考，但是却在根据领导意愿在实现比较粗糙的三层架构，有点苦不堪言。

有更高效和更成熟的解决方法为什么不建议管理者去使用呢?表达下你的意见也好.

领导意志是不以组员意志为转移的，组员有他熟悉的框架和了解的知识，领导有他了解的框架和了解的知识，当两者不一致的时候，领导会采用他了解的框架来布置开发任务而忽略其他可能更好的框架设计，这就是工作中的领导意志。