十几张表，几十个页面，百人以下同时在线的DB+Web应用，完全可以用JSP+JavaBean搞定。虽然PHP语法精简得多，但JavaBean封装性好，重用性高，IDE支持好，做下来不会比PHP复杂多少。
上百张表和页面，几百个人的中等规模应用，如果是锁定DB+Web的，用个纯Web的框架，像Struts、Webwork、JSF均可，用个数据库连接池，性能要求高的页面搞个把缓存，也不难搞定，用顺了其实不比ASP.NET复杂多少。
以上方案解决了90%的Web+DB问题。
至于最后的10%，那就是真正的企业级应用，决不仅仅是多少张表、多少页面、多少用户的问题。考虑的是稳定性、事务、安全性、扩展性、重用性等等一堆堆复杂问题，这种复杂应用，J2EE（EJB或者Spring+XX+XX+XX）才能解决问题，而且目前是最简单的解决方案。
当然，通过JSP也可实现，但JSP不是强类型的，本身不支持OO，复杂功能的还要靠JavaBean配合完成。
那么首先我们可以不争论到底哪个方式更好的问题，我想很重要的一点就是作为程序员都应该有一种追求更好的精神，如果我是coyizz，目前我的方式可以解决应付当下的问题，那么我目前的方式有没有什么不足，现在的JAVA技术不断进步，有没有更好的方式解决我现在的问题等等，我可能更多的考虑是这样的。
那么，我会更多地了解类似框架之类的东西，是否能为我所用，比如现在是要基于底层的框架新写些Bean再发布上去，那么可不可以在前期分析时就已经考虑到后期可能的扩展，各种接口和功能都已经留好，即使考虑不到那么全面，也可以通过很方便的方法就可以在系统上再进行开发扩展，而基层的人员只需要在某个管理入口中配置自己的实际使用即可？我想banq所一直推崇的Domain Driven Design是可以实现的，也正是为实现这样灵活的开发而提出的，记住软件是要有生命的，要能不断成长的，要有好的框架以使它不致于有一天变成一个巨型的怪物，我们自己也无法控制它了。
那么这样，到时就只有总部的程序员在管理着系统，在一个非常好的框架上（例如IOC模式，非常容易扩展）不断完善系统，而基层使用的人员只需设置自己使用的具体细节即可，同时可以不断提出新的需求建议，由总部来针对其做进一步的开发。
我想上面我所说的也只是一种想象，是希望虚拟个具体一点的例子能更好地说明我的建议：先不要争论孰优孰劣，可以从自己的应用角度出发（因为只有你自己最了解你的需要，同时也只有你才要面对你的问题），多了解一些新的技术，新的思想，能对自己有所补益是不错的，如果能改变自己原来的想法，我想那是更佳的效果，呵呵……
国内的那些个大师们不是吃饱了撑着才搞出这些架构，大家一定要硬着头皮，深入钻研，等知其然后要知其所以然，才会慢慢领悟到软件的精髓。
本人在“轻”与“重”，“快”与“慢”之间痛苦徘徊了好几年，最近总算小有心得，待会撰文写诸位共勉。
gh_aiyz 发表文章: 20/ 注册时间: 2006年02月21日 10:00
为什么这种帖子也能上头条，纯浪费我们的时间
***********/
没有呀，我觉得通过大家的讨论也能学到不少东西呀。
楼主的说法太过武断自然会引来各方面的批评，不过讨论技术问题说明白道理就行，没必要指名道姓XX说。我觉得楼主想要表达的意思是他们的项目结构很简单，规模很小，想采用某些开源框架发现不但学习周期长而且有点杀鸡用牛刀了。。。其实，这里的讨论很多人都已经讲出框架的优点和适用面。一旦接触比较复杂的项目了，不用大家说，开发此项目的人会自然而然发现非常难于维护和扩展，这个时候他自然会发个帖子，介绍一下项目，然后征求大家的建议看看使用哪种框架比较理想。
总之，我的原则是能不用框架的项目尽量不用框架(比如楼主这种小而简单的项目)，如果采用框架一定选个比较合适的(当然，这要求对各种框架都要有一定的理解)，而不是选择最时髦的。
以上是个人意见，讨论问题，楼下的不要带情绪哦
个人学习java框架成本过高,使用时下流行的java框架开发周期长,若没有完整的软件工程UML配置等IDE工具配合去维护跟进文档恐怕,人手维护DOC是若干困难.恰恰国内很多公司都没有这方面的经验.只能蒙眼瞎摸,通常是一个PDM表结构,几份所谓的手写DOC需求,一些SRC的结构管理DOC甚至是先core后逆向.在更新需求或增加模块结构代码时候通常只有COPY,从未考虑过重构,即使考虑重构也无法应付项目赶工,通常程序员都是照COPY无误,反正实现了,客户口就给堵住了.而且人员流动时间通常都是1年左右,若项目期在2年内的,开发者都是只有打一枪换一个地方,这样项目流产早,客户需求无法第一时间实现.以上应该是国内的现状.
我们绕个圈看看.net,它的学习非常快速,开发周期跟vb还快,即使文档人手维护,单查找bug或更新增加需求时候即使不重构,开发也是非常的快捷简单,界面拖放控件,底层sql编写,简单模块推翻重做也easy.项目虽然很烂,但总会保证客户的需求第一时间满足.
请问大家问题:我们做it为谁服务?如何服务?
我认为是为客户服务,要第一时间满足客户需求,同时代替他/她做对其有帮组的事情.
反对滥用xml配置的数据库映射框架如时下的主题orm框架:
项目表过百张,映射配置超过百份,start部署难以忍受,更不用说开发了,难怪人人加班,眼睛通红.
反对滥用xml配置AOP框架:
AOP映射通常都是配置逻辑类映射,所谓的滥用就是改动少的模块也配置一番,如:权限,业务逻辑不是经常变更的.这样映射该映射模块文件非常大,即使分文件也是很痛苦.非必要还是先跳过AOP实现,在扩展或修改时候重构加入.
开发体现主要在重构中,实现多种工厂利用接口的扩展去管理新增或修改的逻辑模块.必要时加入AOP框架管理,可加强项目扩展性.必须安排硬性重构时间约定组成,形成规范约制,这样即使没有框架也是非常好办.
本人很少发言,以上只是我个人的一些观点.大家可以进行针对性的讨论.
图形化是解决问题的根本！
不能图形化表达的东西都是复杂的，不能方便导航，方便编辑的东西都是废物。这就是为什么有了Html还要有dreamweaver,为什么有了.net还要有Studio.Net，为什么有了Spring还要有springIDE,为什么有了struts还要有strutsConsole(后两个做的非常垃圾）...
可惜现在的JAVA界都想占山为王，很容易搞的界面就是没人做。那个垃圾Spring更是变态之极，将个类的初始化搞的复杂无比还没有图形化支持，N年前VB,DElPHI将控件拖来拖去的时候，这个玩意还不知在哪猫着呢!
什么XML方便更改更是放狗X! 不懂代码就改XML，你借他十个胆他也不敢！相对于开发成本来说，菜鸟们搞个远程桌面简直是小菜一碟。应用是一个整体，配置和代码往往是纠缠在一起的，尤其是那个什么狗XSpring掺合进来的时候。
一家独大有一家独大的好处，至少人家会养一帮闲人，倒估个界面出来，现在的JAVA整个一盘散沙。。。.
[该贴被drinkjava于2007年05月26日 05:46修改过]
多数业务逻辑用ORM来表达的确比较清晰和简单。
性能要求高的地方，难免要写sql或存储过程，这样性能才有保证。
有些复杂查询，用ORM简直是自找罪受，用Spring的JdbcTemplate解决起来很快。
service这个层也不能省，否则客户端要求一变就苦不堪言。
在联机事务应用方面，客户端还是用C/S（RCP）更能让客户接受，清晰的service层可以很轻松地实现替换，或C/S、B/S并用。
而web层，像SpringMVC、Webwork这类高解耦的框架，可以根据不同需要采用不同的视图。尤其是SpringMVC，初上手太灵活、太繁琐，但精通后可以适应Web的种种复杂要求，值得深入学习。
[该贴被lgx522于2007年05月31日 08:38修改过]
1.研究基础知识,将来可以开发自己的模块
2.不研究基础知识,拿别人建好的模块搭积木.
其实这两个方面各有各的应用领域,看你是搞什么的,如果你只是为其他企业开发系统,完全可以只是搭积木,就象banq说的,只要知道电视机电冰箱是怎么用的就行了.如果你要做基础的东西,就要从基础学起,就要研究电视机电冰箱的结构了.这纯粹是应用方向的不同,并没有绝对的对错之分.
但我不同意banq的是对搭积木的过分强调,你的观点固然正确,但只是对一部分人来说,对另一些人来说就不一定了.就象治感冒的药,药本身并没有什么正误之分,若是拿来治感冒,就是好药,是治病良药.若是拿来治烧伤,就是误人子弟了.
国内现状虽然是需要搭积木的人多些,好像"钱途"也更广阔些,但决不能没有了搞基础的人,不然若干年后(其实现在也已经是了),我们也就只能玩玩搭积木了. 如果别人那天不想给你积木玩了,就只剩哭鼻子了.看看伊拉克的例子,想当年伊拉克是多么的富足啊,要啥有啥,据说个别人的马桶都是纯金打造.可一旦被封锁了,饭都吃不饱了,可怜啊.这也是我国要致力于打造自己的核心技术的原因(至于龙芯之类的东西,是被小人蒙骗,可以不讨论了).
现实一点,如果哪天你的积木里被人埋了一颗遥控炸弹(木马后门之类的),想想看,好像一点都不好玩哦!
所有我认为,需要赚money的,可以搞搭积木,多快好省,有兴趣研究底层的,尽可以向下钻研,到时自己搞个积木出来(小心,多数会失败的),卖给那些搭积木的人.