web开发框架以及分层

    前两天，我们经理总是问软件分层有什么好啊，使用那些struts、hibernate、spring又有什么好啊。这里我作为一个日志说说我自己的看法。

  当然，即使不分层，也能做出软件来，但我们应该思考怎么做才能最好？如果说分层不好，那么不分层的优势又在哪里呢？？如果说分层有性能的损耗，那么性能损耗在哪里呢？？如果不分层，软件工程思想中的“分而治之”的原则启不受到了质疑？

  有人说，分层是为了减少代码量，如果分层是为了减少代码量，那怎么能减少，代码的重用也许会减少一些，但是程序更多的是业务，我们关心的也只是业务，试问分层的意义就是为了减少代码量？

以下是我的观点：我的一般分层思想是：action、service、dao。如果将来业务有什么变动，只需要关心service就可以了，有人问为什么。如果你说dao经常需要变动，那意味着你数据库经常需要变动，很显然，是你设计有问题；如果你说数据库连接之类的异常，那是你应该怀疑你自己的编程能力，因此dao是不会有变化的。在看action，action就是一个控制器，调用service和将service处理的结果返回前台，会改变吗？显然也不会。最后就是service，如果出问题，基本上可以直接定位到这里。如果不分层，那将会是灾难性的后果。<o:p></o:p>

  我们经理的观点做web开发很简单，提交标单-〉响应-〉后台处理-〉返回。难道真的就这么简单吗？还认为使用一个框架之前必须知道他好在哪里。以下是我的看法：

  如果web开发真的那么简单，要这些框架做什么？如果你能在不使用这些框架的情况下开发出自己的好框架而且项目能按时完成，如果你能说你能做到，那恭喜你，你可以不用。如果你在使用每一个框架之前都要说他好在哪里，那你还是不要用好了。早期CGI出来的时候，人们觉得他好；后来servlet出来的时候，觉得编程简单，否定了CGI；再后来JSP出来了，可以在页面写代码，避免了很多重复性的工作，于是否定了servlet；再后来自定义标签出台，觉得在JSP写太多java代码，不太好；后来看到ASP.NET的组件化技术很好，于是JSF出来了，人们说他好；再后来Spring MVC框架设计的完美，说他也很好；再后来webwork和servlet API相分离，又说他好；最近struts2流行起来，又说他好。如果当你能说出他到底好在哪里，也许这个技术已经不再是他的核心优点。

  我认为实践是检验真理的唯一标准，既然有很多人有成功的案例，我们为什么不去使用这个东西。不要忘记，生产率是我们一直追求的目标。但是不排除市场上有炒作的成分，比如说dojo。这个东西你要是说他的优点，你最少可以说出50个，但是谁在实际项目中使用？也许有，但至少我没有看到是怎么用的，我尝试过dojo的0.4版本，性能的问题实在叫人无法忍受。我觉得dojo就有市场炒作的成分。比如说hibernate，也许有很多人知道他的优点，即使你不知道，你完全可以使用，因为成功的案例太多了，性能更是没得说。如果你认为hibernate不应该使用，那EJB3.0你是不是也觉得不应该使用了呢？

   总之我的观点就是：软件分层是必须做的。至于框架，不应该问用不用，而应该问用什么？要选用实践检验过的框架，毕竟实践是检验真理的唯一标准。

 

同意楼主的，实践是检验真理的唯一标准，框架要在实际应用中用了才知道的

我们用的是ibatis感觉也不错

顶一个！

我赞同你们经理的观点。

公司开发的必须是经过反复测试和明确把握的东西。

规范的东西好处会很多的.

我们经理的观点做web开发很简单，提交标单-〉响应-〉后台处理-〉返回。
--------------------------------------
我也同意这个观点。

事实上，真正能深刻理解这个过程的所谓B/S程序员并不多。


----
另外，这种争论其实很无聊，不用/用了又怎样？

还不是整天有人争论这个好，那个不好？
还不是天天都有新的框架不断涌现，长江后浪推前浪，前浪死在沙滩上？
还不是被所谓的IT巨头忽悠来忽悠去？
还不是被客户的变态需求搞的死去活来？

yishengtanxi......

其实各种设计模式都是在解决一个问题－解耦

---------------------------------------------

照你这么说，那什么也别用了，直接开发一个tomcat或者jboss，然后自己发明一种语言去做。如果没有IT巨头的话，那我们今天就不是程序员，而是在街上乞讨。如果程序员连B/S的基本过程也不了解的话，我相信没有一个公司愿意要的，也就不存在web这样的web程序员。

说的一点没错，这就是我们选用框架的标准之一。传统的ASP将所有代码写在页面中，对于小的项目而言，是可以实现功能的，但对于大的项目而言，那将是灾难性的。更何况后期维护也是我们必须考虑的因素。

Web开发进行分层，主要是由项目的复杂程度而定的。每一层之所以能够成为一层，都和项目的具体情况而定。

所谓的表示层、业务逻辑层和持久层的划分，是众多软件前辈根据多年的经验总结出来的最佳实践。要说理由，可以说上3天3夜也说不完。这和项目的大小没关系，而是一个综合的考虑。当一个项目非常简单，也无需什么扩展性，你硬要引入那么多的框架，分那么多的层次，那就是没事找事，对吧。

完全同意这样的说法，但是现在的软件开发要求没有扩展性我觉得太少见，但我个人认为项目的大小也存在着一定的制约，如果项目很大，不分层的话，后果是不可设想的。毕竟开发阶段分层的目的就是为了分工明确，如果一个比较大的项目没有分工，后果也是不可想象的。当然可以按照模块进行划分，但公司是为了提高生产力，随着xp开发的流行，我们需要权衡是按层划分职责还是模块。