peterwei
- 浏览: 247776 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
-
zdq19891104：
soufun这个webService太坑爹。。
cxf调用.net webservice之any元素 -
panmingzhi815：
看到这么多的回复，我深感大家也对Hibernate爱恨不舍。我 ...
VO(DTO)模式在分层架构设计中是否需要的扯淡 -
yanglinone1：
太棒了，找半天问题了
cxf调用.net webservice之any元素 -
lyncn：
有个朋友在阿里系里面做架构师，工资也就不到一年25万。
未来怎么走，再次面临offer选择 -
chrissie：
遇到同样的问题！你的文章帮忙解决了~灰常感谢！支持一下！
cxf调用.net webservice之any元素
引子：
前几天，小胖和我说他们公司CTO批他了，说他写的代码不够OO，不够DDD。细问才知道他们CTO在推DDD(领域模型驱动设计).我当时给他的观点是，JavaEE应用是天生贫血的，并不能像ruby之类的语言做到很好的富血，做到DDD。因为这些观点也是N年前讨论过的问题，我记得冒似robbin当年还下过定论：Java天生是贫血的。所以有了ruby之流做RAD快速开发。但当seam到spring roo的出现与完善，富血DDD在Java里也变得可行起来（此论言之尚早，拭目以待）。我以前也和别人争吵过哪个更好，现在我的思想又受到了一些冲击，你呢？世界在发展，我们的思想是不是也应该与时俱进呢？
贫血vs富血
我们来回顾一下。在企业架构模式中，业务层的实现一般有两种模式：一种是事务角本模式（Transaction script），另一种是领域模型模式（Domain Model）。这两种分别对应贫血和富血。好吧，我们不说这些扯淡的东西，我们简单点说。
所谓贫血，就是一个对象里只有属性，如java中的pojo，要实现业务，要依靠service层来实现相关方法，service层的实现是面向过程的，也就是所谓的transaction script.我们现在大量的分层应用action->service->dao->entity的方式就是这种贫血的模式实现。
所谓的富血就是属性和方法都封装在Domain Object里，所有业务都直接操作Domain Object。Service层只是完成一些简单的事务之类的，甚至可以不用service层。也就是直接从action->entity.
前人总结的一些贫血和富血的对比：
贫血模型的优点：
1.被许多程序员所掌握，许多教材采用的是这种模型，对于初学者，这种模型很自然，甚至被很多人认为是java中最正统的模型。
2.它非常简单，对于并不复杂的业务(转帐业务)，它工作得很好，开发起来非常迅速。它似乎也不需要对领域的充分了解，只要给出要实现功能的每一个步骤，就能实现它。
3.事务边界相当清楚，一般来说service的每个方法都可以看成一个事务，因为通常Service的每个方法对应着一个用例。
其缺点为也是很明显的：
1.所有的业务都在service中处理，当业越来越复杂时，service会变得越来越庞大，最终难以理解和维护。
2.将所有的业务放在无状态的service中实际上是一个过程化的设计，它在组织复杂的业务存在天然的劣势，随着业务的复杂，业务会在service中多个方法间重复。
3.当添加一个新的UI时，很多业务逻辑得重新写。例如，当要提供Web Service的接口时，原先为Web界面提供的service就很难重用，导致重复的业务逻辑（在贫血模型的分层图中可以看得更清楚），如何保持业务逻辑一致是很大的挑战。
富血的优点是：
1.领域模型采用OO设计，通过将职责分配到相应的模型对象或Service，可以很好的组织业务逻辑，当业务变得复杂时，领域模型显出巨大的优势。
2.当需要多个UI接口时，领域模型可以重用，并且业务逻辑只在领域层中出现，这使得很容易对多个UI接口保持业务逻辑的一致(从领域模型的分层图可以看得更清楚)。
富血的缺点是：
1.对程序员的要求较高，初学者对这种将职责分配到多个协作对象中的方式感到极不适应。
2.领域驱动建模要求对领域模型完整而透彻的了解，只给出一个用例的实现步骤是无法得到领域模型的，这需要和领域专家的充分讨论。错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。
4.对于事务等的处理，如果完全DDD,java支持得不够好。
关于Spring roo
引子中小胖公司就是采用Roo完成DDD富血开发。Spring Roo is a popular open-source rapid application development (RAD) tool for Java developers. ，使用命令行或工具操作来生成自动化项目，操作非常类似于rails。Roo可以很好的支持富血的Java DDD。关于roo我也不想说太多，因为我也没有亲自实战过，大家可以google一下。
如果采用roo,只需要
对于一个业务实现
在这里出现了一行@RooWebScaffold注解，做过rails的人会想，这不是rails里面的scaffold吗？没错，通过@RooWebScaffold注解，EmployeeController自动获得了curd的所有功能。
好了，就这么简单，一个domain，一个Controller，我们就可以发布到tomcat中运行了。
这两天又看了一下spring roo,修正一下观点，新的spring roo版本已经可以用DBRE reverse from db.并且好像也很强大。
1.一个entity只需要写属性就行，get set免。
2.简单的增删改查功能，一键生成。
3.通过aspectJ实现编译时aop，完全不影响性能。
4.可以动态查询：如findPersonByNameAndMinMax(),相当于like name,between min to max这样的功能。
5.用Spring roo实现DDD，只有两层Controller层和Entity层。另外Service层（可选），Dao不推荐用了。
6.jms,email,json序列化支持
7.其它说明：开发需要JDK1.6以上。
8.不想用roo时，可以快速删除annotation和相关的jar包等文件。
...
Spring roo架构overview：
AspectJ实现编译时AOP
自动动态查询，自动生成
想了解更多roo内容，可以看看此文：使用Spring Roo ，感受ROR式的开发
http://www.iteye.com/topic/443059
还有看官方文档：
http://www.springsource.org/roo
关于ruby
Ruby我没有使用过，只是有所了解。所以不敢评价。但是当spring roo等框架成熟起来后，java语言就能很好的支持富血，更好的OO，更好的DDD，也能支持web快速开发了。那么我们能不能斗胆问一句：基于Java的开发者，想实现ror一样的web开发，还需要ruby吗？我们没必要向ruby转了吧？
小结：
我们对于新的东西，总是会有一种天生的阻抗性。就如我习惯了贫血的开发模式，有了更OO的spring roo出现时，我内心里还是不大看好它。正如前些天一些人说spring越来越庞大，不好一样，我想他们也是内心的阻抗性在起作用。但一个人要有一个更高的视野，时刻准备一些东西，当风暴来临时，可以从容面对。
ps:说一下我的观点：
我是多年的贫血模型的实践者，基本上并没什么特别觉得不适的地方，虽然贫血模型不那么OO。其实我对于这个spring roo并不是特别看好。但是需要去了解它，和关注它。(可能又要修正了，看发展情况吧)
国外有一篇文章对spring roo的观点，我是比较赞同的:
When to use Spring roo?
http://java.dzone.com/articles/when-use-spring-roo?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+(Javalobby+%2F+Java+Zone)
我抽出几个重要的出来：
What is Spring Roo?
“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience.
Spring Roo is awesome for CRUD-Clients!
Spring Roo is good for learning Technologies!
Spring Roo is NOT good for complex Projects (yet)...
Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!
My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.
基本上结论就是，你必需知道spring roo,因为它确实很好，但是你必需知道什么时候使用它，什么时候使用其它的开发方式。用它来生成简单的，业务不复杂的crud应用，或者只是用来学习新技术。不要使用spring roo来做复杂的，大型的项目。
别人的一些观点：
1.Martin Flowler批贫血的文章：AnemicDomainModel
http://martinfowler.com/bliki/AnemicDomainModel.html
也许在现有的技术和框架支持下，Java的DDD和富血应用已经开始成熟。ruby是否可在java界休止了呢？等待先行实践者分享经验。
欢迎拍砖，谢绝谩骂！
附件为:spring roo快速学习文档
你是不是多打了一两个零？
这个世界上有多少人能写过超过1000w行代码？
1000W行，代码写的多好像也不能说明什么问题，用不用OO和能否写出好软件没什么必然联系吧~~~
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？
你这是纯属抬杠。哈哈。你怎么不说500个字段呢？在我们做过的大多数项目里，哪有出现那么多字段的。你这是拿特例来说事。特例自然有特例的处理方法。比如一些报表系统，有很多字段的。可以事前统计，做物化视图等。对于海量的数据，自然有相应的处理技术。这些都不是hibernate擅长的地方，也就是剩下那10%左右不能做的事情。
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
前些天我们公司的开发工程师向我提议说要不要采用0配置，全部采用注解等。我基本上不赞同的，基本上用xml配置文件，分好层和模块了，以后几个项目庞大时，因为有好几个子系统，更好理解和以后维护一些。
嗯，分层和分模块之后更容易维护和开发，也能更容易理解。因为团队不是你一个人，那是很多人在协同开发。
是啊，当年Spring刚出的时候多好，多么轻，就因为这个才用它的，现在是越来越大了，臃肿
像spring roo这种东西，基本上是srpingmvc（Controller）-->domain了，也就是说不用service层和dao层了。把一些事务和其它的东西交给spring去做了，这也就是spring越来越大的原因之一。我发这个贴子，是想看看有多少人在用spring roo来做ddd,以及他们处理复杂逻辑的经验。
我不是很认同srpingmvc（Controller）-->domain这样的模式，虽然这样可以DDD，但是对于层级之间的关系和职责就不是很清晰了，也要导致srpingmvc（Controller）变得很大，很慢，很不好处理。。
很认同这个观点，层级关系清晰，职责明确，该是做什么的就是做什么的
好像这个思路已经有很多年了。你说Spring roo只适合做demo,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。
哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。
Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。
我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。
过几个月正式上线以后，如果没有大问题，会争取将框架开源的。
真有你说的那么好吗？拭目以待。我赌你们肯定参考了别人的东西。可以申请开源，让大家看看。
有点道理。不过DDD总要落地实现系统的吧。大多数DDD都走的Rich模型吧。怎么能说没有关系呢？
好像这个思路已经有很多年了。你说Spring roo只适合做demo,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。
哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。
Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。
我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。
过几个月正式上线以后，如果没有大问题，会争取将框架开源的。
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
谁不服就打谁，我靠，有些事情只能武力解决问题。
哈哈。这个大棒在手确实很重要。幸好我们没有老油条。要说有，就是我。但像你们那种鬼团队，老油条必然很多。武力的话，小心受挫！哈哈。
改变别人的想法是扯淡的事情。。。
如果靠说就能改变别人，你以为你是naruto啊 。。
如果用自己的思想重写代码在给其它技术看，那真的是一个漫长的过程，而且你写出来以后，别人也会觉得，”这样也可以，那样也可以嘛”，结果是没有结果
所以，最最最最最可行的办法是你当老大，你说的算
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
谁不服就打谁，我靠，有些事情只能武力解决问题。
哈哈。这个大棒在手确实很重要。幸好我们没有老油条。要说有，就是我。但像你们那种鬼团队，老油条必然很多。武力的话，小心受挫！哈哈。
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
谁不服就打谁，我靠，有些事情只能武力解决问题。
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
前几天，小胖和我说他们公司CTO批他了，说他写的代码不够OO，不够DDD。细问才知道他们CTO在推DDD(领域模型驱动设计).我当时给他的观点是，JavaEE应用是天生贫血的，并不能像ruby之类的语言做到很好的富血，做到DDD。因为这些观点也是N年前讨论过的问题，我记得冒似robbin当年还下过定论：Java天生是贫血的。所以有了ruby之流做RAD快速开发。但当seam到spring roo的出现与完善，富血DDD在Java里也变得可行起来（此论言之尚早，拭目以待）。我以前也和别人争吵过哪个更好，现在我的思想又受到了一些冲击，你呢？世界在发展，我们的思想是不是也应该与时俱进呢？
贫血vs富血
我们来回顾一下。在企业架构模式中，业务层的实现一般有两种模式：一种是事务角本模式（Transaction script），另一种是领域模型模式（Domain Model）。这两种分别对应贫血和富血。好吧，我们不说这些扯淡的东西，我们简单点说。
所谓贫血，就是一个对象里只有属性，如java中的pojo，要实现业务，要依靠service层来实现相关方法，service层的实现是面向过程的，也就是所谓的transaction script.我们现在大量的分层应用action->service->dao->entity的方式就是这种贫血的模式实现。
//贫血代码示例：
Account.java
Public class Account{
private String name;
private Long num;
get set…
}
AccountService.java
Public class AccountService{
public List findAccountBySomething(String abc){}
public void addAccount(Account a){}
public void otherBiz(){}
}
所谓的富血就是属性和方法都封装在Domain Object里，所有业务都直接操作Domain Object。Service层只是完成一些简单的事务之类的，甚至可以不用service层。也就是直接从action->entity.
//富血代码示例
Account.ava
Public class Account{
private String name;
private Long num;
public List findAccountBySomething(String abc){}
public void addAccount(Account a){}
public void otherBiz(){}
}
前人总结的一些贫血和富血的对比：
贫血模型的优点：
1.被许多程序员所掌握，许多教材采用的是这种模型，对于初学者，这种模型很自然，甚至被很多人认为是java中最正统的模型。
2.它非常简单，对于并不复杂的业务(转帐业务)，它工作得很好，开发起来非常迅速。它似乎也不需要对领域的充分了解，只要给出要实现功能的每一个步骤，就能实现它。
3.事务边界相当清楚，一般来说service的每个方法都可以看成一个事务，因为通常Service的每个方法对应着一个用例。
其缺点为也是很明显的：
1.所有的业务都在service中处理，当业越来越复杂时，service会变得越来越庞大，最终难以理解和维护。
2.将所有的业务放在无状态的service中实际上是一个过程化的设计，它在组织复杂的业务存在天然的劣势，随着业务的复杂，业务会在service中多个方法间重复。
3.当添加一个新的UI时，很多业务逻辑得重新写。例如，当要提供Web Service的接口时，原先为Web界面提供的service就很难重用，导致重复的业务逻辑（在贫血模型的分层图中可以看得更清楚），如何保持业务逻辑一致是很大的挑战。
富血的优点是：
1.领域模型采用OO设计，通过将职责分配到相应的模型对象或Service，可以很好的组织业务逻辑，当业务变得复杂时，领域模型显出巨大的优势。
2.当需要多个UI接口时，领域模型可以重用，并且业务逻辑只在领域层中出现，这使得很容易对多个UI接口保持业务逻辑的一致(从领域模型的分层图可以看得更清楚)。
富血的缺点是：
1.对程序员的要求较高，初学者对这种将职责分配到多个协作对象中的方式感到极不适应。
2.领域驱动建模要求对领域模型完整而透彻的了解，只给出一个用例的实现步骤是无法得到领域模型的，这需要和领域专家的充分讨论。错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。
4.对于事务等的处理，如果完全DDD,java支持得不够好。
关于Spring roo
引子中小胖公司就是采用Roo完成DDD富血开发。Spring Roo is a popular open-source rapid application development (RAD) tool for Java developers. ，使用命令行或工具操作来生成自动化项目，操作非常类似于rails。Roo可以很好的支持富血的Java DDD。关于roo我也不想说太多，因为我也没有亲自实战过，大家可以google一下。
如果采用roo,只需要
对于一个业务实现
@Entity
@RooEntity
@RooJavaBean
@RooToString
public class Employee {
@NotNull
@Size(max = 200)
private String name;
@Temporal(TemporalType.TIMESTAMP)
private Date birth;
}
//EmployeeController代码如下：
@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = Employee.class)
@RequestMapping("/employee/**")
@Controller
public class EmployeeController {
}
在这里出现了一行@RooWebScaffold注解，做过rails的人会想，这不是rails里面的scaffold吗？没错，通过@RooWebScaffold注解，EmployeeController自动获得了curd的所有功能。
好了，就这么简单，一个domain，一个Controller，我们就可以发布到tomcat中运行了。
引用
Roo功能目前还不很强大，比如还不能根据配置的数据库链接直接从数据库表来生成Entity，以及前端表示层使用JSP和绑定Spring MVC(基于Spring 3.0支持REST)等，但是这些改进目标已经纳入其roadmap中。说一下另一个框架Seam对于富血也做得不错了，但还不是完全富血，同样也绑带了JSF。
这两天又看了一下spring roo,修正一下观点，新的spring roo版本已经可以用DBRE reverse from db.并且好像也很强大。
1.一个entity只需要写属性就行，get set免。
2.简单的增删改查功能，一键生成。
3.通过aspectJ实现编译时aop，完全不影响性能。
4.可以动态查询：如findPersonByNameAndMinMax(),相当于like name,between min to max这样的功能。
5.用Spring roo实现DDD，只有两层Controller层和Entity层。另外Service层（可选），Dao不推荐用了。
6.jms,email,json序列化支持
7.其它说明：开发需要JDK1.6以上。
8.不想用roo时，可以快速删除annotation和相关的jar包等文件。
...
Spring roo架构overview：
AspectJ实现编译时AOP
自动动态查询，自动生成
想了解更多roo内容，可以看看此文：使用Spring Roo ，感受ROR式的开发
http://www.iteye.com/topic/443059
还有看官方文档：
http://www.springsource.org/roo
关于ruby
Ruby我没有使用过，只是有所了解。所以不敢评价。但是当spring roo等框架成熟起来后，java语言就能很好的支持富血，更好的OO，更好的DDD，也能支持web快速开发了。那么我们能不能斗胆问一句：基于Java的开发者，想实现ror一样的web开发，还需要ruby吗？我们没必要向ruby转了吧？
小结：
我们对于新的东西，总是会有一种天生的阻抗性。就如我习惯了贫血的开发模式，有了更OO的spring roo出现时，我内心里还是不大看好它。正如前些天一些人说spring越来越庞大，不好一样，我想他们也是内心的阻抗性在起作用。但一个人要有一个更高的视野，时刻准备一些东西，当风暴来临时，可以从容面对。
ps:说一下我的观点：
我是多年的贫血模型的实践者，基本上并没什么特别觉得不适的地方，虽然贫血模型不那么OO。其实我对于这个spring roo并不是特别看好。但是需要去了解它，和关注它。(可能又要修正了，看发展情况吧)
国外有一篇文章对spring roo的观点，我是比较赞同的:
When to use Spring roo?
http://java.dzone.com/articles/when-use-spring-roo?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+(Javalobby+%2F+Java+Zone)
我抽出几个重要的出来：
What is Spring Roo?
“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience.
Spring Roo is awesome for CRUD-Clients!
Spring Roo is good for learning Technologies!
Spring Roo is NOT good for complex Projects (yet)...
Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!
My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.
基本上结论就是，你必需知道spring roo,因为它确实很好，但是你必需知道什么时候使用它，什么时候使用其它的开发方式。用它来生成简单的，业务不复杂的crud应用，或者只是用来学习新技术。不要使用spring roo来做复杂的，大型的项目。
别人的一些观点：
1.Martin Flowler批贫血的文章：AnemicDomainModel
http://martinfowler.com/bliki/AnemicDomainModel.html
也许在现有的技术和框架支持下，Java的DDD和富血应用已经开始成熟。ruby是否可在java界休止了呢？等待先行实践者分享经验。
欢迎拍砖，谢绝谩骂！
附件为:spring roo快速学习文档
分享到：
评论
98 楼
hypercube1024
2011-05-02
IcyFenix 写道
downpour 写道
一个没写过超过1000w行代码的人，我认为连说OO的资格都没有。
你是不是多打了一两个零？
这个世界上有多少人能写过超过1000w行代码？
1000W行，代码写的多好像也不能说明什么问题，用不用OO和能否写出好软件没什么必然联系吧~~~
97 楼
peterwei
2011-05-02
key232323 写道
peterwei 写道
key232323 写道
为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？
你这是纯属抬杠。哈哈。你怎么不说500个字段呢？在我们做过的大多数项目里，哪有出现那么多字段的。你这是拿特例来说事。特例自然有特例的处理方法。比如一些报表系统，有很多字段的。可以事前统计，做物化视图等。对于海量的数据，自然有相应的处理技术。这些都不是hibernate擅长的地方，也就是剩下那10%左右不能做的事情。
96 楼
key232323
2011-05-02
peterwei 写道
key232323 写道
为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？
95 楼
peterwei
2011-05-01
key232323 写道
为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
94 楼
key232323
2011-05-01
为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
93 楼
manysysy
2011-04-30
一种是事务角本模式（Transaction script）
应该是事务脚本吧
应该是事务脚本吧
92 楼
icefire
2011-04-29
最近看了jbpm4。
感觉比较靠近ddd。
而且相对来说，jbpm4中service和entity职责划分挺好。
jbpm4整个又是大量使用了命令模式，使得service很简单，真的成为一个单纯的对外接口。
总之jbpm4的参考价值还是很大的。
感觉比较靠近ddd。
而且相对来说，jbpm4中service和entity职责划分挺好。
jbpm4整个又是大量使用了命令模式，使得service很简单，真的成为一个单纯的对外接口。
总之jbpm4的参考价值还是很大的。
91 楼
飞雪无情
2011-04-29
peterwei 写道
zhyuan 写道
不建议使用在大型系统中使用自动化代码生成工具，不管是自己开发的还是开源的，自己开发的代码生成工具还好，开源的出了问题就麻烦了。开发的时间节省了，维护的时间却大大的增加了。
前些天我们公司的开发工程师向我提议说要不要采用0配置，全部采用注解等。我基本上不赞同的，基本上用xml配置文件，分好层和模块了，以后几个项目庞大时，因为有好几个子系统，更好理解和以后维护一些。
嗯，分层和分模块之后更容易维护和开发，也能更容易理解。因为团队不是你一个人，那是很多人在协同开发。
90 楼
飞雪无情
2011-04-29
whaosoft 写道
唉 和lz想法一致啊 感觉spring越来越胖了 有点ejb2的影子了
是啊，当年Spring刚出的时候多好，多么轻，就因为这个才用它的，现在是越来越大了，臃肿
89 楼
飞雪无情
2011-04-29
peterwei 写道
像spring roo这种东西，基本上是srpingmvc（Controller）-->domain了，也就是说不用service层和dao层了。把一些事务和其它的东西交给spring去做了，这也就是spring越来越大的原因之一。我发这个贴子，是想看看有多少人在用spring roo来做ddd,以及他们处理复杂逻辑的经验。
我不是很认同srpingmvc（Controller）-->domain这样的模式，虽然这样可以DDD，但是对于层级之间的关系和职责就不是很清晰了，也要导致srpingmvc（Controller）变得很大，很慢，很不好处理。。
88 楼
飞雪无情
2011-04-29
tedeyang 写道
贫血富血与service、dao等没有必然联系。
service一般是被视为面向接口设计和facade模式，所谓“服务层”，意义是很清楚的，只是提供业务逻辑层的统一包装和调用，这一层与DDD也没有任何冲突。DAO也如此。
service一般是被视为面向接口设计和facade模式，所谓“服务层”，意义是很清楚的，只是提供业务逻辑层的统一包装和调用，这一层与DDD也没有任何冲突。DAO也如此。
很认同这个观点，层级关系清晰，职责明确，该是做什么的就是做什么的
87 楼
peterwei
2011-04-28
icewind_yx 写道
peterwei 写道
icewind_yx 写道
领域模型只是一种思路，为什么没有流行起来是因为没有真正能够支持领域模型的充血Domain Object框架存在，Rails靠近了这个思路。由于java死板的语法的原因，在java中实现Domain Object，现在来说还不现实。除非再出现一个类似Hibernate那样划时代的Domain Object ORM框架出来。
另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。
又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。
另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。
又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。
好像这个思路已经有很多年了。你说Spring roo只适合做demo,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。
哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。
Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。
我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。
过几个月正式上线以后，如果没有大问题，会争取将框架开源的。
真有你说的那么好吗？拭目以待。我赌你们肯定参考了别人的东西。可以申请开源，让大家看看。
86 楼
peterwei
2011-04-28
Tin 写道
贫血、充血这些只是持久化对象或者数据传输对象的一些设计决策，它很大程度上收到语言的限制，尤其是持久化数据模型要很多奇技淫巧。
我要说的是这和DDD和OO没有半毛关系。
DDD是设计方法，它贯穿了从需求的分析到设计到实现，是一套方法论。它集中在统一术语，梳理业务模型，让代码与系统的领域术语之间达成一致，从而减少因此产生的众多需求/实现之间的不匹配问题。而且DDD的很多重要变化发生在领域模型的演化过程中，和细节关系不大。而且xDD方法族都强调的是以某种因素作为驱动力，先行。这和前面说的贫血、充血没有直接关系，只是一般按照领域模型驱动并保证功能相关的代码尽量放在一起的话，一般需要充血的持久化模型而已。
OO是设计方法，有一些基本准则，目的是增加代码的可维护性。
请不要讨论贫血、充血的时候扯DDD和OO，那还离得很远。充血的模型很有可能不是DDD出来的！
我要说的是这和DDD和OO没有半毛关系。
DDD是设计方法，它贯穿了从需求的分析到设计到实现，是一套方法论。它集中在统一术语，梳理业务模型，让代码与系统的领域术语之间达成一致，从而减少因此产生的众多需求/实现之间的不匹配问题。而且DDD的很多重要变化发生在领域模型的演化过程中，和细节关系不大。而且xDD方法族都强调的是以某种因素作为驱动力，先行。这和前面说的贫血、充血没有直接关系，只是一般按照领域模型驱动并保证功能相关的代码尽量放在一起的话，一般需要充血的持久化模型而已。
OO是设计方法，有一些基本准则，目的是增加代码的可维护性。
请不要讨论贫血、充血的时候扯DDD和OO，那还离得很远。充血的模型很有可能不是DDD出来的！
有点道理。不过DDD总要落地实现系统的吧。大多数DDD都走的Rich模型吧。怎么能说没有关系呢？
85 楼
Tin
2011-04-28
贫血、充血这些只是持久化对象或者数据传输对象的一些设计决策，它很大程度上收到语言的限制，尤其是持久化数据模型要很多奇技淫巧。
我要说的是这和DDD和OO没有半毛关系。
DDD是设计方法，它贯穿了从需求的分析到设计到实现，是一套方法论。它集中在统一术语，梳理业务模型，让代码与系统的领域术语之间达成一致，从而减少因此产生的众多需求/实现之间的不匹配问题。而且DDD的很多重要变化发生在领域模型的演化过程中，和细节关系不大。而且xDD方法族都强调的是以某种因素作为驱动力，先行。这和前面说的贫血、充血没有直接关系，只是一般按照领域模型驱动并保证功能相关的代码尽量放在一起的话，一般需要充血的持久化模型而已。
OO是设计方法，有一些基本准则，目的是增加代码的可维护性。
请不要讨论贫血、充血的时候扯DDD和OO，那还离得很远。充血的模型很有可能不是DDD出来的！
我要说的是这和DDD和OO没有半毛关系。
DDD是设计方法，它贯穿了从需求的分析到设计到实现，是一套方法论。它集中在统一术语，梳理业务模型，让代码与系统的领域术语之间达成一致，从而减少因此产生的众多需求/实现之间的不匹配问题。而且DDD的很多重要变化发生在领域模型的演化过程中，和细节关系不大。而且xDD方法族都强调的是以某种因素作为驱动力，先行。这和前面说的贫血、充血没有直接关系，只是一般按照领域模型驱动并保证功能相关的代码尽量放在一起的话，一般需要充血的持久化模型而已。
OO是设计方法，有一些基本准则，目的是增加代码的可维护性。
请不要讨论贫血、充血的时候扯DDD和OO，那还离得很远。充血的模型很有可能不是DDD出来的！
84 楼
icewind_yx
2011-04-28
peterwei 写道
icewind_yx 写道
领域模型只是一种思路，为什么没有流行起来是因为没有真正能够支持领域模型的充血Domain Object框架存在，Rails靠近了这个思路。由于java死板的语法的原因，在java中实现Domain Object，现在来说还不现实。除非再出现一个类似Hibernate那样划时代的Domain Object ORM框架出来。
另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。
又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。
另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。
又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。
好像这个思路已经有很多年了。你说Spring roo只适合做demo,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。
哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。
Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。
我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。
过几个月正式上线以后，如果没有大问题，会争取将框架开源的。
83 楼
fuyaner
2011-04-28
DDD及Rich模式在当今之中国环境，尚未可行。有搞的，必然是铺路石的命运。
82 楼
beneo
2011-04-22
peterwei 写道
mercyblitz 写道
peterwei 写道
mercyblitz 写道
peterwei 写道
mercyblitz 写道
我又上来骂一句，呵呵。
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
谁不服就打谁，我靠，有些事情只能武力解决问题。
哈哈。这个大棒在手确实很重要。幸好我们没有老油条。要说有，就是我。但像你们那种鬼团队，老油条必然很多。武力的话，小心受挫！哈哈。
改变别人的想法是扯淡的事情。。。
如果靠说就能改变别人，你以为你是naruto啊 。。
如果用自己的思想重写代码在给其它技术看，那真的是一个漫长的过程，而且你写出来以后，别人也会觉得，”这样也可以，那样也可以嘛”，结果是没有结果
所以，最最最最最可行的办法是你当老大，你说的算
81 楼
peterwei
2011-04-22
mercyblitz 写道
peterwei 写道
mercyblitz 写道
peterwei 写道
mercyblitz 写道
我又上来骂一句，呵呵。
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
谁不服就打谁，我靠，有些事情只能武力解决问题。
哈哈。这个大棒在手确实很重要。幸好我们没有老油条。要说有，就是我。但像你们那种鬼团队，老油条必然很多。武力的话，小心受挫！哈哈。
80 楼
mercyblitz
2011-04-22
peterwei 写道
mercyblitz 写道
peterwei 写道
mercyblitz 写道
我又上来骂一句，呵呵。
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
谁不服就打谁，我靠，有些事情只能武力解决问题。
79 楼
peterwei
2011-04-22
mercyblitz 写道
peterwei 写道
mercyblitz 写道
我又上来骂一句，呵呵。
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。
我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。
很多系统架构师很容易被洗脑，很少去看非主流技术。
说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。
对不起，我又冲动了！
那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。
官大一级压人呀！多元化的思想，很难形成规模！
哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。
发表评论
相关推荐
Manning Spring Roo in Action 完整版。
spring roo 官方文档。很权威的东西。最新版本1.1.5的。
spring roo是快速开发java的框架，支持spring mvc/security/tiles/webflow/test,也可以自己修改。
在使用 Spring ROO的时候 除了要在eclipse中安装Spring ROO 插件以外 还在要在电脑上配置 Spring ROO环境 （和jdk的环境配置一样）
NULL 博文链接：https://ximeng1234.iteye.com/blog/2205872
NULL 博文链接：https://moonshinewoo.iteye.com/blog/1835032
spring的新技术，使开发变的更简单，更明了。在spring的基础上，推出了roo。
spring-roo-2.0.0.RC1.zip
SpringRoo 官方文档-版本2.0.0.RC1
spring roo actionspring roo actionspring roo actionspring roo actionspring roo actionspring roo actionspring roo action
spring roo的eclipse工程。可象普通java工程一样调试，跟Felix无关。注意其中的.lanches文件需要copy到你的eclipse workspace的.metadata\.plugins\org.eclipse.debug.core下
Spring Roo 是SpringSource新的开放源码技术，该技术主要面向企业中的Java开发者，使之更富有成效和愉快的进行开发工作，而不会牺牲工程完整或灵活性。无论你是一个新的Java开发人员或经验丰富的架构师，Spring Roo ...
spring-roo里面有打包，还有需要的东西，这是release版本
springroo快速学习
具体可以查看我的博客 http://blog.csdn.net/qiumeng_1314/article/details/77711867
Spring Roo - Reference Documentation
Spring ROO 1.1.0 升级到 1.1.1中文文档
vaadin,spring-roo,war包和源码
s-springroo2-sample_code
Spring Roo Document Welcome! If you’re reading this, then you’ve undoubtedly heard about Spring Roo from a friend or colleague, or perhaps you read about it online or saw a presentation about it. ...