spring的初级问题

[小笨和漂向北方]

背景：不是java程序员。但断断续续用过java.所以哪里说的不对请指教！

刚知道新的spring controller都是用annotation (RequestMapping) 直接在代码里定义url pattern了，这样不就木有灵活性了吗？需要修改时只能改代码，然后重新编译。记得以前都是写在ｘｍｌ里的。。。

是不是ｘｍｌ的配置实在复杂，干脆把controller当一个“ｘｍｌ＂来用啦？

如果是这样，其实ｓｃａｌａ更合适，可是它不争气啊。。。

思路混乱，请大家慢喷！

[小笨和漂向北方]

1。有关测试，俺是没有做过你这些“大”项目，只能简略的谈谈我们的实践。我们的开发任务可能有分散在全国各地的几个部门协作，也可能只是我们本地承担。我们有in-house的tower servers做测试，便宜量又足！同时，每个中心都在数据中心有机柜，在提供prod environment的同时，也承担dev和测试的作用。如果开发的软件比较复杂（比如分布式系统），在budget允许情况下(一般这样的项目肯定是百万级以上)，我会预先采购一台4，5w价位的rack server，配置会高些，128GB RAM, Xeno 10coreX2, SSD就算了，SAS15K就挺实惠，然后全虚拟化环境，并且争取做到一个component一个VM。这样每个dev group只需要针对一个VM工作。对测试来说，VM内部的测试PE不参与，只有当components integration testing阶段时，我才会weigh in。 像你描述的测试环境，应该不是unit testing了，如果是interface testing, 不妨试试我的方法。当然，如果你们的运行环境过于庞大，难以搭建小scale的VM cluster进行物理隔离，那你就只能contact vendor了。。。不过，你说的那个神马osgi不就应该是干这个的吗？ 2。关于软件hot swappable，load balancer是最通用，也是我认为最有效的。这个热插拔本身就是一个花哨的玩艺,像RAID的hot swap理论上可以随时进行。而对软件来说，exception太多，用在企业信息系统上，冒险吧？ 3。有关架构师的问题，我们是谁的项目，谁就是这个project 的tech lead，一般至少是PE，就是架构师的职责，其它team member，有PE,SE等等。project manager肯定会有，product manager要看情况，如果需要，就相当于公司内部的甲方。 4。今天有空好好看了一下你以前的回帖，完全被你忽悠的那些英文缩写搞懵了！同事都说我是小富即安，木有档次。。。放狗搜了一下，才发现你说的都是办公自动化的软件和企业信息集成的平台。还去看了ibm websphere的white paper，什么SOA, WSDL,RPC,一下子又找到感觉了！ sap bmp的demo让我震惊啊！感觉那还是写程序吗？拉个流程出来，代码都自动生成啦！当然，针对每个企业，估计你们这些consultant还要做二次开发。我说我们单位跑sap的那几台sever怎么总是内存紧张！ 5。至于架构师写不写代码的问题，你们的可能不写。但我肯定写，我自己的项目，最核心最难的部分肯定要自己来啊！demo写好，剩下的就留给手下做了。至少这是我的风格。 还有你的博客，我去看了，完全木有你在这个帖子里的犀利吗！当然，你的头像也有点略吊！那是在灰机里还是在高铁上自拍的啊？我觉得你还是跟我在论坛里吵架来的痛快吧？ 还有，在你的主页上列出的技能里，貌似你是做前端的啊，什么ssh，sap啥的你都木有写啊！是准备转后台啊，还是忘记更新啊？

引用 51 楼 ooppookid 的回复:

[猿人林克]

引用 54 楼 micropentium6 的回复:

引用 51 楼 ooppookid 的回复:

1.博客里写的东西都是自己没事做的，多数属于笔记，和专业无关。你从那篇里面看到都是前端的东西啊，我印象中我没写过前端的博文。 专业：bpm(不是bmp。。，主要是企业的生产管理，例如电网的配、调、监控、设备等等这些系统的各种管理模块(真正的系统核心都是甲方的研究院干的事，一般不会委托我们乙方来做)，大部分要和erp集成，自动化办公什么的还真没做过)/webdynpro/sap ce、ep/s2sh/ejb/信息系统集成等等，架构师肯定算不上，顶多是个设计。 其他的就是跟着架构团队讨论一下方案，做做系统内部的设计(比如搭搭框架啊、设计一下实体、表结构啊这些东西)；服务器方面略懂，但也就停在操作配置层面；sap的大多数产品以及模块也是略懂，大框框没问题，细节我也不关心，真用到在扒拉文档也来得及。 2.不是我们的运行环境大，是sap的产品本身就是这样（我倒是想给每个开发的pc上都来一套，但是也只能控制自己公司的，其他公司的人一样会统一开发），so，他们才会osgi分模块来统一开发，这也是他们给出的方案之一。 至于你说的，也就是多个开发环境，每个项目当然都是这么做的，最理想的情况是每个开发一套，但是现实么。。 3.我不知道你们是哪个行业的，乙方找的是哪些公司，用的是哪些产品(还是说从零开始开发)，看你描述可能是ibm？也可能你们本身就是一个咨询+产品，不过这都是乙方啊，甲方还有开发设计的工作，那我落伍了。据我所知至少国内的部分企业自己投人做的东西只会是核心，比如电网的配调、石化海油的生产(这些都是企业研究院这帮人搞得，技术水平也可以说比较烂，原因是太过安逸，而且会用到ssh、sap的产品么？)，其他系统，例如erp什么的都是找外部来搞。 至少在我们的行业里，pm一般都甲方的人（乙方协助，一般都有一个pmo组织，一般都是ac的几个人，也就是我前面提到的5K+一个人天的高端consultant），而具体方案都是乙方牵头（基本上一个项目大家分，若干咨询公司一家一块，做不同的模块），甲方基本只关心时间和成本（包括产品的采购、包括服务器、软件、其他设备），我这里说的甲方一般就是指企业总部（下面分公司只会出人配合（要不是总部集中部署，还要提供服务器之类），没有管理我们的权限）。 而且我不知道百万级的项目是指什么项目？当然我不知道你们行业的预算是怎么做的，是项目整个的预算，还是一年的预算。我们行业里，现在是个项目预算都是百万级别的，我们给一个生产企业做个主数据平台的预算还200W+(一期，1500+人天，十几个人6个多月，现在应该在做到三期了吧。而且据说这个生产企业一年集团(不算下面各公司自己找人做的项目)的信息化预算就要做到1千五六百w（道听途说）。举个例子，一个已经运行了好久的营销系统，要做多语言，光我们技术这边就估了将近700多人天，十个人的团队3个半月，你算算多少钱吧。一二百万的预算，对于ac、普华、德勤这种出个差4星+上下班打车的公司光人员成本都亏死了，就不考虑管理成本了。 另外，这不是吵架，也许只有你认为是吧（所以叫你少侠，可能是搞理论搞太多了，说话的方式太不成熟，建议以后和别人讨论时，说出你的论据，然后根据你的论据说事，不然怎么让别人信服呢，哪怕是你摘别人的东西来说明也行啊，不要"完全被你忽悠的那些英文缩写搞懵了！"、"用在企业信息系统上，冒险吧？"，你先说出那些缩写你蒙了、这么做有什么风险（没有实际论据说说你能想到的地方也行啊），然后你再侃侃而谈，不然你这两段话在和人沟通的时候就是两段废话)，这才真正只有吵架时候会用到，毫无理由的论说一通~(没有吵架的意思啊，只是建议，你可以无视这段)。 这个帖子结了吧，不是一个行业还是讨论讨论技术比较好，而且看你的经验，也许看的书比较多，理论不错，说到实际项目你几乎没有什么经验，也就不要那你听别人说的或者自己凭空想的东西和我讨论了，没什么太大价值，耽误两个人的时间，如果是讨论技术我欢迎（所以不要在开场：有学到什么啦。。太好啦之类的，我估计我说了这么多你没实际体验过，永远不能明白我说的东西）。

[小笨和漂向北方]

[quote=引用 57 楼 ooppookid 的回复:] 羊毛出在羊身上，这些大公司的所谓consultant谱都大着呢！住套房算啥，人家的charge是从上飞机就开始算了。但到我们这都免谈。当然这是我的雇主的事，俺是木有啥可以炫耀的。 你接触 或者听说的大型企业erp类项目较多，巨大的承包金额，高大上的软件提供商，浮夸的解决方案，使你自己产生了错觉，一叶障目。 企业信息系统是市场蛋糕的一块，对软件提供商和硬件厂商而言。 我想知道的你都告诉我了，也对你表示了谢意。 脚踏实地吧，骚年！

[小笨和漂向北方]

隔行如隔山吧？“说到实际项目你几乎没有什么经验“你说的这些项目我的确木有经验，木有做过jee么。。。你一直是在用你最擅长的来和我最不了解的之一在讨论。。。很高兴你分享了很多自己的经验！你想要quantifiable好啊！不过貌似你在这说来说去，也都是经验之谈吧？和你聊了半天，一直听你说来着，还真没得空听别人说！ P.S.，ac、普华、德勤在我们这可不敢摆这个谱，爱干不干，不敢赶快给别人腾地方！ 你说结贴就结贴喽，不过还是很感谢你抽出时间写出这么多我不知道的东西！再次感谢！

[mooonchen]

引用 60 楼 micropentium6 的回复:

谢谢啊！如果把这种url pattern和类的对应放在xml文件里岂不是更灵活？

楼主不要纠结了，我在工作中就是把url pattern写在代码里的，也没什么问题呀。 确实写在xml里更灵活，但是你想想，一个项目，要有多少个url pattern，少则上百，多则上万，如果用xml管理，这个xml要存多少数据，谁来负责管理这个xml，如果多个程序员同时修改同一个xml，很容易出现冲突，导致开发效率降低。所以url pattern写在代码里更方便，效率更高。希望能够帮助到你。

[tianyeren00]

首先，如你所说，DI/IOC的确是best practice。我们可以说，不会用DI的程序员揍不是好程序员。一个C程序员在喊，我不吊OO，木有用DI！好吧，看看qsort最后一个参数是啥？函数指针。那是啥？一个接口。。。 [/quote] 首先，如你所说，DI/IOC的确是best practice。我们可以说，不会用DI的程序员揍不是好程序员。 这个谈不上好坏的。只不过你接手了使用spring的项目，那自己必须先把spring的基本应用了解了，不用太深，能看懂基本的配置应用就可以了。就像一个使用java web 架构好的系统，现在要兼容一块C语言做的模块，那么开发人员就必须学习C语言一样。 spring di提高了代码的扩展性和可维护性？最可扩展的代码永远是自己写的代码，使用框架的代价就是扩展只能按框架的要求展开。 当然可扩展的代码是自己写的代码，自己写的耦合度很高的代码，牵一发而动全身；和解耦较高的代码，只需修改很少处的代码的维护代价还是有区别的。 但spring xml hell据说已经导致DI本身木有可维护性了，特别是对大规模项目这种本来应该从中受益的项目。spring的xml 据说DI本身木有可维护性，这个不太理解。spring面向的是接口编程，使用xml配置的是接口的具体实现。如果想换实现了，直接新增了一个接口的实现类，同时修改一下xml的配置就好了。 关于注解的使用，前面说过了，确实增强了耦合度，跟解耦的理念背道了。 可问题来了：多大叫规模大呢？怎样定义大规模？这里加上“复杂”是不是更合适？一个“大规模且复杂“的系统开发需要spring DI？ 这是个很软的概念。如果一个人spring使用的非常熟练，他可能任何web项目都会使用spring来架构。如果一个人习惯struts的话，那可能任何项目都会往struts上靠近。这个是使用的习惯问题。规模的大小一个跟项目的模块量，跟实现的功能多少有关系，另一个就是跟开发者对技术的使用熟练程度有关系。 这个纯粹是对技术的见解，没有攻击的意思。 扯一点题外的，现在java的框架中，spring是使用率最高的框架了。一个原因就是spring的DI，再就是spring可以和struts，hibernate，iBATIS这些开源框架很好的融合。[/quote]

[Golden_Dog]

没看完，留个爪。。。。。 我想问楼主一个问题：C++语言特性上是不是真的甩java几条街？？听说什么糖什么的很牛逼。。。（纯属娱乐提问，只是想拓宽一下眼界，看看用过两种语言的人怎么说，以后好正确的吹吹牛。）

[小笨和漂向北方]

谢谢你的帮助！ 向我在最开头说的，咱不是java程序员，所以那个例子用的也不好，那时spring mvc,而不是spring。前面已经有人指出了。我其实是想讨论的spring di的使用方法。 十年前，当spring刚出现时，所有的文章，书，文档都在讲di如何如何好，用xml定义如何的可以解耦合。风水轮流转啊，十年后，还是spring，用@autowire写在@component代码里来指示bean,，然后在定义@Configuration来加载bean，这真是一下回到十年前啊！ 我理解，这样做有很多好处，可十年前的怎么说？你现在可以理直气壮的指出xml种种不好，当年就木人看出来吗？ 其实咱没打算争出个啥来，你说的都对！但看过帖子后，至少你可以知道，这些所谓best practice的趋势无非是十年河东，十年河西，根本算不上什么道理。。。不信你就走着瞧，annotation的坏处不久大家可能就都体会到了。 所以呢，只选对的不选贵的

引用 61 楼 mooonchen 的回复:

[quote=引用 60 楼 micropentium6 的回复:] 谢谢啊！如果把这种url pattern和类的对应放在xml文件里岂不是更灵活？

楼主不要纠结了，我在工作中就是把url pattern写在代码里的，也没什么问题呀。 确实写在xml里更灵活，但是你想想，一个项目，要有多少个url pattern，少则上百，多则上万，如果用xml管理，这个xml要存多少数据，谁来负责管理这个xml，如果多个程序员同时修改同一个xml，很容易出现冲突，导致开发效率降低。所以url pattern写在代码里更方便，效率更高。希望能够帮助到你。[/quote]

[小笨和漂向北方]

总结帝，你在整理一下ooppookid的发言呗，其实也挺有意思的，向我这个不做企业信息系统的人看了挺长见识的！

引用 62 楼 tianyeren00 的回复:

[mooonchen]

我直接回答楼主的问题，url pattern确实要写在代码里，这样确实不怎么灵活。 但是，你想想，url这么重要，能轻易改么，如果url改了，那么调用url的程序是不是也要一起改才行？ 实际做项目中，可能会修改ip和port，但这并不影响代码中的url pattern，一个url pattern一旦定下来，就不能改了，因为修改的话，会导致调用url的程序也要修改，如果别人已经写好了调用程序，你就不能再修改了url pattern了。 希望能帮助到楼主。

[小笨和漂向北方]

引用 59 楼 mooonchen 的回复:

我直接回答楼主的问题，url pattern确实要写在代码里，这样确实不怎么灵活。 但是，你想想，url这么重要，能轻易改么，如果url改了，那么调用url的程序是不是也要一起改才行？ 实际做项目中，可能会修改ip和port，但这并不影响代码中的url pattern，一个url pattern一旦定下来，就不能改了，因为修改的话，会导致调用url的程序也要修改，如果别人已经写好了调用程序，你就不能再修改了url pattern了。 希望能帮助到楼主。

谢谢啊！如果把这种url pattern和类的对应放在xml文件里岂不是更灵活？

[u010792874]

注解还是很方便的

[empty_null]

我写完的程序，能跑起来就行了，用注解方便很多。什么解耦，重用，这个我不care。某些需要频繁改动的我写在xml中，比如用户名密码。

[小笨和漂向北方]

引用 66 楼 empty_null 的回复:

我写完的程序，能跑起来就行了，用注解方便很多。什么解耦，重用，这个我不care。某些需要频繁改动的我写在xml中，比如用户名密码。

你这就不java了啊！ java程序员都是言必解耦，重用的。。。 when the framework is too big to be manageable and the project is too important to fail, the compromise must be made regardless of believe or loyalty, huh?

[其实我是真性情]

英文看不懂

[其实我是真性情]

人齐了可以结贴了

[小笨和漂向北方]

那你还跑人家地盘蜜月！

引用 69 楼 lwb314 的回复:

英文看不懂

[小笨和漂向北方]

引用 70 楼 lwb314 的回复:

人齐了可以结贴了

我特么等着面向对象便便孩儿总结发言呢！ 话说他咋还不来！

[cmontxgt]

感谢、学习很多

[爱睡觉的阿狸]

引用 18 楼 micropentium6 的回复:

[quote=引用 17 楼 magi1201 的回复:] 我在java区属于比较菜的菜鸟，就是混的多而已，哈哈。 看你03年就是C/C++板块的明星了，说明你已经是非常资深的程序员啦，哈哈，向你学习。 我是10年才开始接触java的，spring 的 DI 理解一些，aop 一直理解不了，看了几遍，还是没能理解。 最近刚看了servlet，和http协议，要不我们讨论servlet和http吧，哈哈

又开始谦虚了！ 那些老家伙们自持身份，都不敢轻易露面了吧！ 我就是岁数比较资深而已。。。 不过java的web我的确是从servlet开始学起的，还有jsp tld。其实servlet jsp都挺明了简单的，不知道你要聊啥？你能告诉我struts 2和spring controller为毛要用servlet实现而不是filter吗？我觉得filter挺好啊？[/quote] Struts2就是用filter实现的，为什么没人给楼主点出来呢？