|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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，只代码风格和关注点不同。 对不起，我又冲动了！ 那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用. web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。 官大一级压人呀！多元化的思想，很难形成规模！ 哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。 谁不服就打谁，我靠，有些事情只能武力解决问题。 |
| 返回顶楼 | |
|
发表时间：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，只代码风格和关注点不同。 对不起，我又冲动了！ 那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用. web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。 官大一级压人呀！多元化的思想，很难形成规模！ 哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。 谁不服就打谁，我靠，有些事情只能武力解决问题。 哈哈。这个大棒在手确实很重要。幸好我们没有老油条。要说有，就是我。但像你们那种鬼团队，老油条必然很多。武力的话，小心受挫！哈哈。 
|
| 返回顶楼 | |
|
发表时间：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，只代码风格和关注点不同。 对不起，我又冲动了！ 那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用. web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。 官大一级压人呀！多元化的思想，很难形成规模！ 哈哈，你就敢保证你们团队里是统一思想的？你们只是每个人憋在心里而已。大家都隐而不发，心里很多小九九谁也不知道谁罢了。我们是比较open.不过比较open也挺头疼的，小弟们总会提出各种各样的idea。还要说服他们。 谁不服就打谁，我靠，有些事情只能武力解决问题。 哈哈。这个大棒在手确实很重要。幸好我们没有老油条。要说有，就是我。但像你们那种鬼团队，老油条必然很多。武力的话，小心受挫！哈哈。 改变别人的想法是扯淡的事情。。。 如果靠说就能改变别人，你以为你是naruto啊 。。 如果用自己的思想重写代码在给其它技术看，那真的是一个漫长的过程，而且你写出来以后，别人也会觉得，”这样也可以，那样也可以嘛”，结果是没有结果 所以，最最最最最可行的办法是你当老大，你说的算 |
| 返回顶楼 | |
|
发表时间：2011-04-28
DDD及Rich模式在当今之中国环境，尚未可行。有搞的，必然是铺路石的命运。
|
| 返回顶楼 | |
|
发表时间：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,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。 哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。  Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。 我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。 过几个月正式上线以后，如果没有大问题，会争取将框架开源的。 |
| 返回顶楼 | |
|
发表时间：2011-04-28
贫血、充血这些只是持久化对象或者数据传输对象的一些设计决策，它很大程度上收到语言的限制，尤其是持久化数据模型要很多奇技淫巧。
我要说的是这和DDD和OO没有半毛关系。 DDD是设计方法，它贯穿了从需求的分析到设计到实现，是一套方法论。它集中在统一术语，梳理业务模型，让代码与系统的领域术语之间达成一致，从而减少因此产生的众多需求/实现之间的不匹配问题。而且DDD的很多重要变化发生在领域模型的演化过程中，和细节关系不大。而且xDD方法族都强调的是以某种因素作为驱动力，先行。这和前面说的贫血、充血没有直接关系，只是一般按照领域模型驱动并保证功能相关的代码尽量放在一起的话，一般需要充血的持久化模型而已。 OO是设计方法，有一些基本准则，目的是增加代码的可维护性。 请不要讨论贫血、充血的时候扯DDD和OO，那还离得很远。充血的模型很有可能不是DDD出来的！ |
| 返回顶楼 | |
|
发表时间：2011-04-28
Tin 写道 贫血、充血这些只是持久化对象或者数据传输对象的一些设计决策，它很大程度上收到语言的限制，尤其是持久化数据模型要很多奇技淫巧。
我要说的是这和DDD和OO没有半毛关系。 DDD是设计方法，它贯穿了从需求的分析到设计到实现，是一套方法论。它集中在统一术语，梳理业务模型，让代码与系统的领域术语之间达成一致，从而减少因此产生的众多需求/实现之间的不匹配问题。而且DDD的很多重要变化发生在领域模型的演化过程中，和细节关系不大。而且xDD方法族都强调的是以某种因素作为驱动力，先行。这和前面说的贫血、充血没有直接关系，只是一般按照领域模型驱动并保证功能相关的代码尽量放在一起的话，一般需要充血的持久化模型而已。 OO是设计方法，有一些基本准则，目的是增加代码的可维护性。 请不要讨论贫血、充血的时候扯DDD和OO，那还离得很远。充血的模型很有可能不是DDD出来的！ 有点道理。不过DDD总要落地实现系统的吧。大多数DDD都走的Rich模型吧。怎么能说没有关系呢？ |
| 返回顶楼 | |
|
发表时间：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,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。 哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。 Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。 我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。 过几个月正式上线以后，如果没有大问题，会争取将框架开源的。 真有你说的那么好吗？拭目以待。我赌你们肯定参考了别人的东西。可以申请开源，让大家看看。 |
| 返回顶楼 | |
|
发表时间：2011-04-29
tedeyang 写道 贫血富血与service、dao等没有必然联系。
service一般是被视为面向接口设计和facade模式，所谓“服务层”，意义是很清楚的，只是提供业务逻辑层的统一包装和调用，这一层与DDD也没有任何冲突。DAO也如此。 很认同这个观点，层级关系清晰，职责明确，该是做什么的就是做什么的 |
| 返回顶楼 | |
|
发表时间：2011-04-29
peterwei 写道 像spring roo这种东西，基本上是srpingmvc（Controller）-->domain了，也就是说不用service层和dao层了。把一些事务和其它的东西交给spring去做了，这也就是spring越来越大的原因之一。我发这个贴子，是想看看有多少人在用spring roo来做ddd,以及他们处理复杂逻辑的经验。 我不是很认同srpingmvc（Controller）-->domain这样的模式，虽然这样可以DDD，但是对于层级之间的关系和职责就不是很清晰了，也要导致srpingmvc（Controller）变得很大，很慢，很不好处理。。 |
| 返回顶楼 | |
