我们应该怎样看待框架

楼主确实把《企业应用架构模式》读的非常透彻，佩服佩服。所谓的框架，只不过是一种工具，而工具的效果取决于使用工具的人！

中国的软件行业都是不负责任的。

做软件最重要的都看成本。根本没人想过可维护性和安全性。

搞JAVA都用框架，一上来就SSH，都不想为什么用，难道真的那么缺钱吗？写代码怎么了？难道写配置就比写代码轻松？配这个真的就那么快？OK，做完了，框架里的不足也被你带进项目了，别人写的项目，安全性、普及型是个问题，不是每个人都那么了解框架，不是每个框架都那么安全合理。

我觉得做软件还是自己用自己的框架比较好，不反对借鉴，但坚决反对“拿来主义”。

框架总是需要的，如果没有现成的，没多久你自己就整出一个框架来了。

软件开发中有很多复杂的问题，随着你的开发，很多问题就会慢慢凸显。比如我们起初想自己做个工作流框架，但是编来编去发现跟jBPM越来越像，而且我们竟然在重复研究Petri网理论里面已经很完善的东西。再如规则引擎，我自己写了一个，但是发现抽象来抽象去，跟Drools的模型也越来越像。

其实这并不奇怪，因为我们做工作流，和jBPM一样，都是参照了wf规范和Petri，编规则引擎，也都是参照了正向推理。
我特佩服老外的一点，也是比较信任他们的一点就是，他们的框架都是有非常深厚的理论基础的，然后又辅之以实践经验，菲常完美的结合。你看jBPM一个Token的transit，写了好多代码，但是完全是按照Petri理论实现的。
你再看Hibernate，里面的那些映射关系，在Fowler的企业应用架构模式中论述过。

因此Rod在《J2EE Development without EJB》中强调的，你一定不要自制框架，劳民伤财

 

我觉得你是本末倒置了，如果你先看了Fowler的企业应用架构模式，你可能就不这么认为了。

为解决问题而制造了麻烦

lz，你提的这个对待框架的态度我是赞同的。
只不过这个问题的原因不是所谓需求导致的。
问题的本质是，现在软件框架的选择太多了：

软件大厦的基石是什么？从计算机体系结构，汇编语言，到高级语言，框架，平台，整合应用...今天的一切，从来不是每次另起炉灶的结果，而是站在了巨人的肩膀上。

回到对框架的态度上，我们要不要学习，学习到什么程度，是自己产生需求的时候才去学习，还是把它学会了放在工具箱里，需要的时候拿出来，这才是我补充说明的内容。

如果说我们产生了需求才去学习，那么我们不会有今天的软件世界了，也学还处在很原始的阶段。好在学习编程理论，计算机网络，操作系统，没有那么多的选择，所以大家都理所当然的去用，去学习，而没有人讨论他们存在的必要。但是框架的选择太多了，所以我们迷茫了，不知道该不该用，好不好用，用了好不好。但是软件产业并不会停步,更不会退步...

假如今天的网络TCP之外有108中传输协议各个自立门户，实现的方法和封装的层次各不相同，每个人都会花眼吧。也许一大部分人会犯错误，所以问题是选择太多了，而不是需求太多了。我认同Spring的原理和成功，但我也不反对EJB的思想，事实上，今天的Spring还没有取得当年EJB的成就，为软件产业做出的贡献，也没有EJB大。

你不是说不知道该不该用，好不好用吗？那么这篇文章就是谈这个问题的，正文说了第一点，我再用例子补充如下：

      我认为我的观点和Rod的循证架构是一致的，你首先要搞清楚你到底需要什么，比如虽然Rod说J2EE Development without EJB，但是他也很明确的指出，并不是所有情况都不要使用EJB，你要看你需要的是什么，不要相信任何一个（包括我在内的）架构师的话，做自己的垂直切片。举个例子，如果你需要在业务层管理session（在这点上Rod和Gavin King的观点不一样），也就是需要Session Bean，并且支持多种客户端（远程客户端和Web应用），你如何使得用户在Web客户端和远程客户端中切换时不会丢失Session，或许EJB就是一个现成的好方案。再比如，如果你是做信息系统工程项目，那么可能你遇到的情况是开发语言换了好多种，而数据库从来没换过（企业信息系统中还是Oracle是主导的吧），这样的话你把业务逻辑写在经过精心设计和规划过的存储过程里可能更好；而如果你是做产品的，需要适应多种数据库，那么Hibernate来屏蔽这种迁移，就是好的决策。

 

      另外，还要看第二点，就是大家的评论，都是ORM，为什么你选择Hibernate而不是EJB3，不是TopLink；都是Web MVC框架，你为什么选Struts2，为什么不选一个山寨Web MVC框架。

 

      这个道理再简单不过了，你去买数码相机，那么多种，不同的像素，不同的光学变焦，是否带广角，用的是SD还是MS，要不要单反，要不要全画幅，这根据什么？当然是你的需求！第二，你是买尼康的，还是买佳能，还是买爱国者的，要不要看看评论，800万像素+6倍光学变焦和1000万像素+3倍光学变焦哪个更好？

 

 

        因此我说，你用不用框架，用什么框架都是由你的应用场景决定的~~然后应对每种场景，Java社区都有相应的框架（虽然现实比这个数量要少的多），它们蕴含了不同的架构哲学，设计理念，供你选择，这难道是框架的错吗？

 

         另外，作为知识储备的学习，和为了需求而学习，那是不一样的，后者是必修课，前者是选修课。

 

 

 

此话题最后一贴：

 

lz，感觉我们在说的不是同一个问题，所以再讨论下去没有意义了。你是对框架选择在一个方向上做了一个确定的结论，而我在认同你的结论的同时，补充了另一种可能。Spring的作者把EJB归结为实现分布式系统的一个框架，其实EJB是提出了J2EE向上发展的一个思路。

标准化，有着官僚，荣誉等等一切缺点，但它的优点也是显而易见的。

最好是开明专制，然后是民主自由，最后是垄断独裁。我的个人思想。

您所谓的另一种可能是什么？是说框架可以起到教导的作用吗？如果是这样的话，我倒也认同，因为不同的人可能会选择不同的起点，有人喜欢以理论为起点，有人喜欢从赤裸裸的使用Java起步，而有人则觉得使用框架更好。

 

但是您有两个说法不太准确的地方：1Rod认为EJB是一个分布式对象编程模型，而分布式对象！=分布式系统，Fowler在企业应用架构模式提出第一定律：不要分布你的对象！而Rod多次在自己的专著中提及并表示赞同。我们应该分布的是服务。2 J2EE的价值是统一了当时多种中间件（消息，交易，表现，对象，等），制定了一个标准，而EJB的作用是把那些标准服务做了个封装，使得你实现一个EJB，就可以自动拥有那些有价值的服务了。因此，J2EE的意义远远大于EJB，EJB只是一个分布式对象组件模型，所以我觉得是否是“向上”还有待商榷~~