|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-17
IcyFenix 写道 downpour 写道 一个没写过超过1000w行代码的人，我认为连说OO的资格都没有。
你是不是多打了一两个零？ 这个世界上有多少人能写过超过1000w行代码？ 光看代码量，没用。 要思考，代码量也有足够，但决不一定要到100w那个层次。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
itstarting 写道 引用 3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。 我倒不觉得把两者过于绝对化——非要弄个势不两立的态势不可——然后做出了胜利的二选一才是真正的结论。 我感觉这无非是一些设计思路而已，各有市场。 这个我完全同意你的说法。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
tedeyang 写道 贫血富血与service、dao等没有必然联系。
service一般是被视为面向接口设计和facade模式，所谓“服务层”，意义是很清楚的，只是提供业务逻辑层的统一包装和调用，这一层与DDD也没有任何冲突。DAO也如此。 service可以deleagte DomainObject来实现具体功能，DomainObject也可以通过切换DAO impl来改变自己的持久化策略。 贫血对象、涨血对象（提到这个我就想起蚊子）的本质是对象是否除了数据还能有行为。 在贫血对象模式下，对象的行为被提出，一般用DAO，Service来分别分流对象的持久化和功能封装，而更重要的是DAO,service往往不是设计为只针对一个Object，这就轻易解决了对象的职责不容易理清的设计难题。 service其实也没有排斥DDD，你完全可以在service中调用富血对象完成具体业务逻辑。 大多数观点我是赞同你的。比如贫血和富血的定义。还有用service层来处理复杂的逻辑。但是我们大多数的应用，dao就是简单的crud并且没有事务存在，在现有可行技术下，dao层有些人已经摒弃。像spring roo这种东西，基本上是srpingmvc（Controller）-->domain了，也就是说不用service层和dao层了。把一些事务和其它的东西交给spring去做了，这也就是spring越来越大的原因之一。我发这个贴子，是想看看有多少人在用spring roo来做ddd,以及他们处理复杂逻辑的经验。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
唉 和lz想法一致啊 感觉spring越来越胖了 有点ejb2的影子了
|
| 返回顶楼 | |
|
发表时间：2011-04-17
zhyuan 写道 不建议使用在大型系统中使用自动化代码生成工具，不管是自己开发的还是开源的，自己开发的代码生成工具还好，开源的出了问题就麻烦了。开发的时间节省了，维护的时间却大大的增加了。
前些天我们公司的开发工程师向我提议说要不要采用0配置，全部采用注解等。我基本上不赞同的，基本上用xml配置文件，分好层和模块了，以后几个项目庞大时，因为有好几个子系统，更好理解和以后维护一些。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
最后修改：2011-04-17
downpour 写道 让一个Domain Object承载所有的逻辑方法就是OO？让Domain Object的属性上承载那么多Annotation就是OO？现在所谓的CTO，程序都没写过几行就在那边胡扯什么OO，一个没写过超过1000w行代码的人，我认为连说OO的资格都没有。
任何的开发方法和模式，都不能和程序开发中最基本的最佳实践相违背。在Java中，让Domain Object和Service Layer过度膨胀都是错误做法。只有两者结合，才能写出可维护的代码来。程序员在这里需要权衡的，是哪些逻辑应该放在Domain Object里面，哪些逻辑应该放在Service Layer中。 哈哈，我的观点也是这样的。OO并不是说承载了所有逻辑方法就是OO了，而要看各种设计思想的应用。对于大量的annotation,其它我也不大感冒。所以我也想知道用spring roo的情况下，如何处理复杂逻辑的。因为spring roo不用Service层，只有controller层-->直接到Domain层。 ps:我和小胖甚至说他们公司的CTO和主要技术决策者是在用项目来learn新技术和方法，丰富自已的履历。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
itstarting 写道 引用 3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。 我到觉得简单的软件用领域模型更方便点。 是的，我的观点也是。上面的第3点是以前别人总结的观点！不是我的观点。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
IcyFenix 写道 downpour 写道 一个没写过超过1000w行代码的人，我认为连说OO的资格都没有。
你是不是多打了一两个零？ 这个世界上有多少人能写过超过1000w行代码？ 1000w，确实是一个很大的概念。我承认我没有达到。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
peterwei 写道 IcyFenix 写道 downpour 写道 一个没写过超过1000w行代码的人，我认为连说OO的资格都没有。
你是不是多打了一两个零？ 这个世界上有多少人能写过超过1000w行代码？ 1000w，确实是一个很大的概念。我承认我没有达到。 这不是很大的概念，是一个基本不可能完成的任务。 即使你非常勤奋，每天写300行代码，一年365天不休息，从刚刚出生0岁就开始敲键盘，也要敲到100岁才能写完1000w行代码。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
当业务变得复杂时，领域模型显出巨大的优势 这两句不矛盾吗？ 见过的电信标准亲一色都是数据service分离 ，各种各样的manager协调着各方数据 Unix管道的设计哲学是富血还是贫血，面向过程还是面向对象 多少人会把应该写成Add（a，b）的写成a.add(b) 以前写过电信设备inventory系统，得到的体会就是尽量把数据和处理分离，对象当成操作数，而不是操作的主体调用者，除非是它自己的吃喝拉撒，很多方法最早在域对象，后面都被移出去，做了很多无用功，最后的代码越来越接近标准接口的风格 在对象当中加方法太危险，用的时候很开心很方便，当方觉模型出问题的时候很揪心，尤其是被继承 扩散后 看到很多牛人的blog都是倾向c而不是c++来重新构建他们的系统，而且还不是因为性能 框架永远解决的是繁琐而简单的问题，最好让他们止于粘合层，能解决复杂问题的东西叫做产品 |
| 返回顶楼 | |
