项目（框架）架构的抉择

            这是一位网友问我的一个问题，希望我能给他一些建议。我觉得这个问题还是比较的好，我也遇到过这样的问题，也非常的头痛。首先得谢谢STONE对我的信 任，也希望我真的能够给他一些好的建议，也希望有更多的网友（同行）能我和交流，我们以诚相待，相互探讨，相互提高。^_^。
         根据他提供的信息，整理出来如下：
                初始环境： 新的公司，新的项目，新的开发团队。
                角色：项目架构负责人（项目领导）。
                开发语言：JAVA
                熟悉的东西：jsp,servlet,javaBean,jdbc,struts,hibernate（不是很熟悉）
                问题：java世界真是太大了，什么都有。太多的框架，太多的选择，太多的疑惑，到底那个好？那个更适合呢？怎样来抉择呢？我到底是选择struts+ hibernate,还是struts+jdbc，还是jsp+servlet+javaBean+jdbc作为项目的架构呢？
         前些天一些牛人们在比较java、rails、php（http://hgq0011.iteye.com/blog/33975），也有在比较各个 框架(http://www.iteye.com/article/24162),不管是从语言，还是框架，架构的搭配都有太多的东西让我们来选择， 就象我们去商场买东西一样，琳琅满目，看得你眼都花了，挑得你头都晕了，也没有挑出个名堂（我经常是这样的，郁闷）。最后，你只得快刀斩乱麻，选择你满意 的，适应的，物美价廉的，口碑比较好的，售后服务好的，，，，。唉，挑东西也是一件痛苦的事情。那么我们搞开发何尝不是的呢？选择的太多，考虑的因素也很 多，头都大了。对于网友的提供的信息来分析。
            首先，他刚来到一个新的公司，担任项目负责人，其实这样就说明他的责任重大，相对的来说，他的压力也比较大（什么工作都有压力。废话一句）。 那么，老板花那么好的待遇把你请过来，是希望你能帮公司带来效益，能够做出指定的项目，不是请你（我）来上QQ、MSN，，，：（，所以，最好是做出成绩 来，把项目搞定，让老板认可你，觉得你的能力不错。：）
          在来看看他自己的项目经验，掌握的技术。因为他是项目负责人，那么他就应该能把握全局，掌握项目的进度，分析用户需求，搭建开发环境，提供技 术指导。当然，他是管理者，可以把相关的事情，分给其他同事来做，自己都亲历亲为这还不累个半死。：（ 他以前没有用hibernate来开发项目，他在担心自己不熟悉它，怕到时影响到系统的性能，影响到项目的进度。struts他说有个类似项目的例子，自 己也比较熟悉；jsp,servlet,jdbc,javabean这些就不用说，应该搞JAVA WEB开发的应该比较熟悉了。所以，我建议他采用struts+jdbc来开发。
          其次，看看他们的开发团队。这团队是一个新的组建的团队。那么大家的习惯，性格，爱好，，，彼此都不是很熟悉，开发过程中配合可能没有那么 好。这就象打篮球一样。我经常去打球，一般都是半场，3对3的。我平时都是一个人去（身在异乡，为异客），然后，随便和其它的2个人组合一个队，这样下 来，另一个队（一般他们经常在一起打球的）的配合就相对比较好，我们头一两场输的几会比较大，但慢慢的熟悉了，配合好起来了，以守为功，那么我们还是可以 和对方抗衡的。所以，刚组建的团队，如果没有技术带头人（熟悉相关技术），那么还是不要采用新的技术。因为我们暂时没有能力去驾驭它，如果贸然使用，会给 相关团队成员带来压力，那么就会有一定的风险。学习它，熟悉它也要一定的时间。
            最后，我建议使用自己熟悉的技术，采用简单的架构去实现项目，等到你把项目做出来了，能用起来了，客户认可了。以后的升级，那是你就可以比较轻松的采用其 它的架构来重构，这样你的风险，压力就相对减少很多了。希望能对他（我）也有所帮助，希望有人能补充（更好的建议）。：）

首先感谢强。给我的帮助，这个是我作为公司的第一个项目，压力大是可想而知的。尤其是一些都不是很熟悉的团队来说。压力。。。。
因为这个框架。我都好久下不了决心。首先，我也想应用新的东西。
毕竟对我，还是对大家来说都是学习的机会。但是又带来了一些负面的影响。
因为你不熟悉，就没有办法控制整个项目的进度和以后的性能。
这是我一直所担心的。许多的朋友给了我许多的建议。都是褒贬不一。

最后还是听从了强的建议，采用的框架。我也很熟悉，可能第一个项目吧。要做好。虽然新东西没有！

不熟悉的技术，引入时间比较紧张的项目中时要慎重。一般我的经验是，不要一次引入太多生疏的技术框架。
但最好每次都能用一些新技术新方法，这样不至于与潮流太脱节。

嗯，讲的很好。
用什么框架都一样，只要能满足客户的要求和项目维护简化说行了。

怎么感觉像是数年前的文章。

[quote="stone2958"]
首先感谢强。给我的帮助，这个是我作为公司的第一个项目，压力大是可想而知的。尤其是一些都不是很熟悉的团队来说。压力。。。。 因为这个框架。我都好久下不了决心。首先，我也想应用新的东西。 毕竟对我，还是对大家来说都是学习的机会。但是又带来了一些负面的影响。 因为你不熟悉，就没有办法控制整个项目的进度和以后的性能。 这是我一直所担心的。许多的朋友给了我许多的建议。都是褒贬不一。 最后还是听从了强的建议，采用的框架。我也很熟悉，可能第一个项目吧。要做好。虽然新东西没有！[/quote]

你很幸福哦，赶快的，想要尝试什么就赶快尝试吧，过了这个村就没有这个店了。

    其实如果你对代码要求比较严格的话，你就会经常发现，你的代码有很多东西可以抽取出来，或者做在公共的模块，或者作为框架的底层，我们就简单的拿jdbc来说吧，
    首先，是connection的管理，这点一般用jdbc熟一些的话，都会有管理connection的公共模块，虽然偶尔会碰到性能的问题，但是这点我们暂且压下不表。
    我们查询的时候，每次都要用
    rs.get...("name"),
    rs.get...("id"),
    rs.get...("age"),
    rs.get...("gender"),
    rs.get...("hobby"),
    然后修改数据库的时候，还要拼写update语句跟insert语句，经常还要费很多时间来调试这些多余代码的问题，这时候你就想，不行，我一定要写一个公共模块，省得让我每次都要定这么多代码，于是你的第一个公共模块产生了，然后测试啊测试，改进啊改进，叮叮响，过了几天时间的考验，这个公共模块终于可以放心使用了，项目进度开始快一些了，总算不用再拼SQL了。
   
    后来在做统计模块的时候，突然又发现，之前在用到的一些SQL函数，好像在客户要求的数据库上不怎么行啊，于是又去查了一下资料，又过了几天（可能这次不用几天），然后终于放心，所有的函数都正常了。
   
    接着又不可避免的碰到了分页的问题，你对自己说，不用怕，我上回就写了一个分页的，没有问题！可是Ya的你突然发现，上回的那个分页是用游标实现的，这回客户是要求用SQLServer，唉，SQLServer的游标，不提也罢，想来想去，只好自己拼SQL语句来写分页了，又是count又是top，测了又测之后，又过了几天，啊哈，终于分页的公共模块也做好的，可以放心使用了，好，项目的进度又可以加快了。

    做着做着的时候，发现，咦，好像这表得增加一个字段才行，增加了，然后所有查询的SQL语句加一下，所有insert跟update的代码修改一下，页面修改一下，嗯，现在应该正常了，看起来倒是没什么问题，咦，报表好像不怎么对啊，靠，这边还有调用这个表的代码，妈的，改吧改吧。磨蹭了好几个小时（当然，熟练的话，并不用几个小时），总算看起来都正常了。

    这一回，这个功能中有一次用户请求，访问了好几次数据库，不行，这里应该用个cache，否则性能上会有问题啊，算了，用算法解决一下，尽量少访问数据库好了，我对cache还不熟呢。（写啊写啊，Batch Size，这样多，那样多，Fetch Size。。。，终于，看起来正常一些了）。过了一段时间，靠，这边又要访问好几次数据库，Ya的受不鸟了，性能爱咋的咋的，反正一个地方慢又不要紧。Oh !!!这边也是好几次，这边又是好几次，那边又是好几次。不行了，我老老实实写个cache支持吧，于是又叮叮当当了好几天，终于，有个粗糙的cache出来了，终于速度可以看一些了。后来改进又改进，测试又测试，累死了，老子好不爽啊。

    好像天下有点太平了，啊，你说我这个地方忘记更新你增加的那个子表啊，算了，没关系，我明天看一下代码，这个容易解决点。嗯，我改了那边的代码了，会更新子表信息了。什么？你说取主表的记录跟相应的子表记录列表麻烦啊，没关系，我更新一下处理resultset的公共模块，明天再说。
    Oh ......对这样子复杂的查询好像现在的公共模块支持不了啊，算了，这样子的查询不要用这个公共模块，我们手动写一些代码好啊，别跟我讲这样代码结构很难看，你以为我不知道啊，TMD。

    TMD的，怎么这边的SQL老是运行不了啊，不会是分页底层模块的问题吧，靠，怎么你的SQL语句有这么多order,group by，靠，还有top啊，这当然过不了了，不要吵了，现在没时间改，不理它，直接用个假分页就行了。你又说代码结构难看，小心我抽你哦。

    公司新来一个程序员，看了几天代码，不停的抱怨说，这代码写得真差啊。。。。。。

[quote="stone2958"]首先感谢强。给我的帮助，这个是我作为公司的第一个项目，压力大是可想而知的。尤其是一些都不是很熟悉的团队来说。压力。。。。因为这个框架。我都好久下不了决心。首先，我也想应用新的东西。毕竟对我，还是对大家来说都是学习的机会。但是又带来了一些负面的影响。因为你不熟悉，就没有办法控制整个项目的进度和以后的性能。这是我一直所担心的。许多的朋友给了我许多的建议。都是褒贬不一。 最后还是听从了强的建议，采用的框架。我也很熟悉，可能第一个项目吧。要做好。虽然新东西没有！[/quote]

项目大小和类型呢? 应该详细点

 

我认为越是有压力的项目越是应该采用最熟悉的框架。1 项目控制心里有数 2 团队合作没有问题 3 不会将过多的时间浪费在研究新的问题和新的技术上