如何看待开源

现在比较流行的开源框架组合SSH（Struts,Spring,Hibernat),很多程序员，系统设计师都很热爱他。因为他们认为这样的组合能让所开发的程序逻辑结构变得清晰，易于维护或开发。
但是很多人发现在用了SSH以后，并没有让所开发程序变得逻辑清晰，易维护。这是因为什么呢？要回答这个问题，应该先弄清楚，我们用开源框架来做什么？

我个人认为，我们之所以用开源框架，是因为开源框架能够帮助我们坚决某种问题或是提升某种效率。为什么用Struts？因为他能将显示逻辑和业务逻辑分开，使程序逻辑结构清晰。
为什么用Spring呢？因为它用强大的事务处理能力。而Hibernat呢？能够帮我们解决数据库操作方面的问题。这看来似乎组合在一起非常好。大多问题都得到解决了。但是实际上呢？

在我所管理的项目当中，用这三种框架开发周期多出了三分之一或更多。查看代码才发现，写了很多接口，每个action，每个数据处理，业务处理都有接口，然后是实现类。这当然看起来很标准，
理想情况下修改BUG或是功能只要改实现类，但在实际当中是不可能的。至少我和我所看到过的程序员也好，系统设计师也好从来没有实现过。每个接口设计出来以后不可能是一点儿都不改动的，
大多数情况下改一个小小的BUG要从页面到action到每个接口，每个实现类一层一层的修改。工作量和工作的复杂度就可想而知了。

因为没有用其它的显示控制标签，在显示层都在用struts标签，有时侯一个简单的显示逻辑需要写很复杂的struts标签。难懂不说，工作量也加大了。有时侯还不理想。

Spring呢，有很多人把action以及大多数类都用Spring来管理，改一个东西又要改spring里面的东东又要改struts里面的东东，可谓牵一发而动全身，曾经碰到过一个程序员改一个小小的BUG用
用了一周时间的。当然我也知道他确实这一
周里都在改代码。

Hibernat呢，确实是一个好东西。但是因为用了Hibernat，很多人员就认为坚决不能在代码里出现SQL语句了，其实这是一个很危险的思想。有很多很好的数据查询组件可以用，给它一个SQL能帮你
做不少事情，但是为了不能SQL语句，就用Hibernat写分页，写查询。在页面上用实体对像类组织显示列表等等，忙得不亦乐呼。不知道这些人有没有想过这样付出的代值有没有必要？

我说这些并不是说这三个东西不好，也并不是说SSH有多遭，只是在选框架之前，我们要搞清楚，我们用这些框架来做什么？

我们用这些开源框架是来帮我们解决问题的,不是给们来添乱的.当我们发现一个东西这样用会给我们带来麻烦时，那就不要这样用了。其实程序逻辑结构清晰这个东西远远不是几个开源框架就能搞定的
事情。关键在于开发团队有一个良好的统一的编程习惯和一个良好的分包设计思想。为什么几个人写的程序比一个人写的程序要难读懂，就是因为每个人的编写习惯不一样。如果一个系统在设计上结构
足够清晰，开发团队有一个统一的良好的编程习惯，就算是不用什么框架，程序逻辑结构同样会很清晰，很容易维护。

曾经在struts2.x推出时，在网上有说struts1.x才是框架中的经典，如果同时用struts2.x和struts1.x开发过项目，我相信就会这样认为了。我个人认为在软件这行里没有所谓的经典，只有最合适。
C语言够经典了吧，你用CGI开发一个B/S系统看看。你还觉得他经典么？不要去拥抱所谓的经典。

有很多人问我，为什么Noka tag里面的dbtable不支持List呀，为什么不支持Hibernat呀，开始我很细心的给他解释，在后来我就懒得解释了，你想用list，你想用Hibernat那你就不是Noka所面对的
用户，Noka不是给这些人用的。noka是给你解决问题的，不是给你带来麻烦的，你给noka一个SQL语句，它会帮你解决分页，排序，导出excel，查询等等一系列问题。如果你非要自已来解决这些问题
那你就不是Noka的用户了。在我看来，这是自已给自已找麻烦。这就像你用struts，为什么页面验证大多情况下还在页面上写js一样。

有很多很好的框架，但是并不是这些框架里面的所有东西都是适合你的项目的。也并不是所有的标准都是适合你的项目的。我们在用一个框架前要想清楚，这种框架能不能帮我解决问题，怎样去解决
这些问题。没有所谓的经典，如果有更好的东西或是更好的途径来解决我们的问题，那么我们就应该用它，而不是抱着所谓的经典不放。

最后给做B/S开发的人员一个建议，多去看看其它语言，尤其是桌面应用系统开发具，他们有很多很好的思想是值得我们去借签的。现在B/S开发也在向组件化方向发展，不是传统的画一个表格就写N多代码
我之所以写Noka就是想让B/S开发变得像Delphi开发那样简单方便。