博客园-光影传说-最新评论

博客园-光影传说-最新评论http://www.cnblogs.com/dreamstec/CommentsRSS.aspx光影传说zh-cnThu, 13 Mar 2008 11:48:00 GMTThu, 13 Mar 2008 11:48:00 GMTcnblogsre: 关于"WebForm和MVC"http://www.cnblogs.com/dreamstec/archive/2008/03/18/1067292.html#1110682光影传说光影传说Mon, 17 Mar 2008 16:52:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/18/1067292.html#1110682从语言层次上、基础构架上说，.NET比JAVA只好不差。领域模型与业务逻辑与具体技术无关也没有错。对于Domain Model，Java能做到的.NET同样能够做到，这点是不用怀疑的。但是在整个面向Domain Model的设计思想上，是指这方面的差距。当然，主要是指这方面人的差距了，包括人的数量上等。
提供的框架的灵活性，业务层组织、服务层组织等这些方面，当然这些有经验的人都可以解决的都不成问题，但是这方面的人是太少了。是指这方面的差距。

光影传说 2008-03-18 00:52 发表评论

]]>re: 关于"WebForm和MVC"http://www.cnblogs.com/dreamstec/archive/2008/03/17/1067292.html#1110584Jeffrey ZhaoJeffrey ZhaoMon, 17 Mar 2008 14:43:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/17/1067292.html#1110584我是从来不觉得.NET和Java领域间有什么差距——这两者有什么是本质区别吗？这些东西有什么东西是不能共享呢？虽然.NET和Java两种实现技术不同，但是领域模型业务逻辑等与具体技术明显无关，而且.NET的基础架构也比Java只会好不会差。比如就拿Domain Model来说，有什么Java领域做得到的.NET做不到？

Jeffrey Zhao 2008-03-17 22:43 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/14/1101336.html#1104872生鱼片生鱼片Fri, 14 Mar 2008 00:45:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/14/1101336.html#1104872_________________________________________________
这个是有点，不过关注的人都会订阅

生鱼片 2008-03-14 08:45 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1104299光影传说光影传说Thu, 13 Mar 2008 12:09:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1104299你说的很有道理，有点突破性的东西，不是Fowler这样的人做出来的，这倒是真的，多是某一个人憋出来的。
原来从05年的充血型模型到现在的贫血型，其实，刚开始的时候，我根本不知道我用的是充血型，后来才知道的。不喜欢重复的没有意义的工作，做完了一个项目之后，就给这个充血型放血了。
只是感觉现在园子里都是发些纯技术的帖子，心里有点不爽，整天Linq TO SQL的用法等等。没有谈论怎么能把ORM与业务层怎么很顺的结合起来，关键还是在于业务层的组织关联，我没有见到多少。我总感觉这些比具体的实际应用要关键多了。
园子里也没有分类之类，帖子很快就沉下去了，也没有人参与进来了。

光影传说 2008-03-13 20:09 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1104281怪怪怪怪Thu, 13 Mar 2008 11:48:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1104281主要是，你说的太粗啦，让大家没法一窥全貌，所以不敢乱说。

这方面工作其实也非常耗精力的，尤其是群策群力的目标往往无法达到。这就是为什么大家会去读Martin Fowler的书的原因：他们这些人专门拿时间来干这个，虽然有时主观色彩浓厚，也经常有不到家的地方，但总比咱们工作做得到位。

另外就是他们能接触很多的人很多的项目，你看Fowler经常说，某某项目的情况怎么怎么样说明什么，某某人对这事的意见是什么。咱们缺乏的主要就是时间和透明性。总而言之，网络上的讨论成本太高，误解也是经常出现的东西之一，无论是在内容上还是情绪上。

但是你发现没有，那些稍微有点突破性的东西，也不是Fowler这样的人做出的，而往往就是某一个人自己那憋出来的。网络在这方面的作用，更多的是帮助好的东西更快速的传播。

我觉得你站的位置特别好，质疑自己才是咱们进步的动力。我唯一不满意的就是，你这么寥寥几句，就想引出砖头来；每个人理解最深的地方不一样，比如我，找不到合适的目标，你叫我怎么扔砖头啊？

怪怪 2008-03-13 19:48 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1104257光影传说光影传说Thu, 13 Mar 2008 11:26:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1104257我的意思您可能理解偏了。我心里是有答案，这种组织方式也在两个项目中得到应用，但是用了，并不能代码就好，就合理。就如泛形用在此处，合理吗？我不能给出一个确切的答案，虽然可以工作。能用不是代表就好，至少我这种代码组织方式，还有很多不合理的地方。我估计想要理清楚这方面的人，应该不是我一个，就是想讨论一下，能不能找出更好的组织方式和规则，把理论与实践结合起来，而又不拘泥于理论。这方面那么多的东西，不能单靠一个人就能做好的，每个人都有思维定式，需要多人讨论才能打破，形成一种更好的更明了的业务层的代码组织方式。这才是我的本意，希望怪怪不要理解错了。

光影传说 2008-03-13 19:26 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1103424怪怪怪怪Thu, 13 Mar 2008 03:25:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1103424唉，你要是心里已经有了自己的答案，就按自己的答案做好了，我从一开始就说了，你的做法没啥问题，只是说如果你要是有疑问，有一些相关的东西你可以看看。我那个帖子也只是刚开始收集，毕竟大家都有自己的事情，谁也没有太多的时间掰的太细。

比如“小生”那篇文章，在我看来就非常画龙点睛，把领域对象与系统边界首先区分开来，其次把与持久化系统打交道的工作划归在了系统边界的控制器对象中，这就已经相当清晰了。这实际上也不是他提出的，而是已经形成理论而且是*得到较大范围验证*的设计和组织方式。

我觉得更具体的东西，只能咱们自己就自己的需要，自己去掌握。要是面面俱到的分析，那得一大厚本书呢(甚至好多本书)，比如"小生"那篇文章的背景，就是基于DDD的理念对事情的看法和假设。有时间有兴趣，咱也只能自己去学习，大家讨论也只能点到为止而已。

如果说到业务层代码组织，话题就又大一圈，光把问题描述出来就要耗费咱们不少精力。比如你这篇文章描述不是很清楚，对"业务操作"这些词汇就没有很好的定义；我只是就我能理解的问题，做个提醒而已，也不是说就有能力把这个疑惑给解答了。

至于ORM什么的，只是个人选择而已，也没有否定别人的意思；框架也是这样：MFC/ASP.NET，都是框架+代码生成的方式，没有说一定不合理。只是但凡一件事，都有第二个甚至更多个视角。设计模式的作者Gamma在几年前的访谈中就说过，从95年之后10来年的实践，他现在对这种方案和当年的一些说法持更谨慎的态度。

另外就是，代码生成能够做到的事，往往也会有另外一种非代码生成的等价或更好的解决方案，当然这话也不是我说的，只是我更多的相信和选择非代码生成这条路。

至于8/2原则之类，也不是只有一种方式能实现不是？在我看来，更多的是区分哪些是核心复杂度。对于七零八碎的东西，八仙过海，更显其能呗～

怪怪 2008-03-13 11:25 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1103274光影传说光影传说Thu, 13 Mar 2008 02:15:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1103274我这里说的，并不完全是持久化与领域逻辑的关系。主要是针对业务层代码的组织，怎么样做，才能更清晰易懂，一个人写的代码另外一个人看起来不会产生阻力，当业务逻辑复杂的时候，能够容易把业务逻辑方便的组织起来，不会冗杂在一起。通过你的Track，也没有看到已经把“持久化与领域的关系”这个问题完全讨论清楚了，更别说业务层的代码组织了。
你说你不喜欢ORM，是因为制造了一大堆PO，那你不能通过别的方式处理，把能够隐藏的东西隐藏在后台处理，这也涉及到组织关系。
对于代码生成，代码生成只是辅助，代替人工工作，这些代码也只是个框架代码，人工要处理的就是在生成的代码上面加入逻辑。在程序里，核心业务的不是很多，超过20张表就比较少了。按80%与20%的原则，应该把80%的精力放在20%的核心业务上。

光影传说 2008-03-13 10:15 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#1103060怪怪怪怪Wed, 12 Mar 2008 23:55:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/13/1101336.html#11030601. 关于持久化与领域的关系

这个问题，你顺着我的TrackBack进去，里面引用了一篇园子里的兄弟的文章，基本上把这些问题怎么看待说清楚了，几句话的事情。

2. 关于ORM。

ORM和存储过程不冲突吧，数据库性能，这又是另一个话题了。我不喜欢ORM，只是因为它制造了一大堆PO，这种形式要么严重的影响其它方面的设计，要么就是需要大量适配，无谓的浪费CPU和内存，同时也造成不少工作量。

更多的， ORM和我的审美严重冲突，虽然有时候不得不向现实妥协。

3. 代码生成

这个方面我无法说出来太多；只是看不少大师都不把代码生成当成真正的解决方案。我的看法是，代码生成很多时候是必要的，其实如果是动态的生成类，或者Emit，还是代码生成（而且还是不安全的代码生成）。

我的想法是，能用逻辑代替代码生成的，就不用代码生成；只有没办法的地方才用它。我的体会是， “没有办法”也是相对的，有的时候去年还没有办法的事，今年就有办法了 :)

最后，关于实用和理论之间的矛盾，确实存在，有些人以解决当前问题为主(不解决不行啊)，有些人在根源上做出不断的尝试(即使是失败的尝试)；没有什么矛盾，分工不同而已。

怪怪 2008-03-13 07:55 发表评论

]]>re: 关于业务层代码的组织http://www.cnblogs.com/dreamstec/archive/2008/03/12/1101336.html#1102763zhangxdzhangxdWed, 12 Mar 2008 13:02:00 GMThttp://www.cnblogs.com/dreamstec/archive/2008/03/12/1101336.html#1102763领域中的对象是否有主动型>>>>这个怎么解释啊？
业务逻辑需要多个对象交互，那就为其建个Service>>>不明白什么意思？

service就是服务，服务一般不会涉及到什么业务逻辑吧... 服务一般就是给
事务，给安全验证，类似的东东..

zhangxd 2008-03-12 21:02 发表评论

]]>