posts - 718, comments - 1240, trackbacks - 51, articles - 0
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

<原載於藍色小舖Blog 阿森的學習筆記 2006/09/04  Mon 12:03 PM>

PetShop有一个名为Model的Project,专门定义PetShop整个Solution中所有Object的Class,另外尚有BLL Project,负责商业逻辑组件的Project,若以OOA/D的角度来看,是否该将这两个Project拆开?还是该合而为一?

若以OOA/D角度来看,OO主要是为了『模拟世界,加以处理』,所以将实际世界中的人事物,透过抽象的方式,用『Object』模拟整个世界,再用『Class』将目前的『Object』做归纳,并用『Class』对未来的『Object』做演绎,而Object本身就应该有Property,Method和Event,而PetShop硬是将Model和BLL拆开,Model专司Property,而BLL专司Method,似乎有违OO中Object同时有Property,Method,Event的习惯。

唯一我认为PetShop可能的考虑是,由于Model Object常常需要当参数传递,若挂着BLL的一堆Method,可能使Model Object过于庞大而占不少内存,事实上,有一本讨论用.NET写n-tier的书面向对象分析设计与实作,他书中的范例程序,就是将BLL和Model就是合而为一,不过究竟PetShop的方式是否较好,我也尚无定论,只是若以OOA/D的观点,似乎将BLL和Model合而为一较为恰当。

Feedback

#1楼    回复  引用  查看    

2006-09-28 01:27 by Dflying Chen      
典型的失血模型,Java阵营早就讨论滥了…………
看看吧:http://www.javaeye.com/article/17579
站在别人的肩膀上 && 多关注其他非.NET领域的想法,才能让我们避免成为井底之蛙。

#2楼    回复  引用  查看    

2006-09-28 01:33 by Jeffrey Zhao      
在这里那些Object是哑对象,只负责保留数据,传递信息。从OO的角度说,这的确不是一个良好的设计,但是其实它们都是Data Transfer Object。
Data Transfer Object是分布式部署的一个常用Pattern,会在多个Tier,甚至所有的Tier上部署。Data Transfer Object可以几种方式,比如DataSet,Typed DataSet等。为项目需要定义Class,如PetShop现在的做法。

#3楼 [楼主]   回复  引用  查看    

2006-09-28 01:43 by 真 OO無雙      
@Dflying Chen

感謝您的建議,他們討論的很詳細很好,真是大開眼界了,其實我也不討厭Java,真的要如你所說,多關注非.NET領域的想法了。

#4楼    回复  引用  查看    

2006-09-28 01:49 by Jeffrey Zhao      
@真 OO無雙
思想是不分.NET还是Java的。

#5楼    回复  引用  查看    

2006-09-28 08:18 by aspnetx      
实体与其有关的逻辑
这个好象去年有人在园子里讨论过吧
我还是倾向于分开

#6楼    回复  引用  查看    

2006-09-28 08:30 by Joey Yin      
倾向于合并。
失血模型的最大缺点就是不够OO,使得设计上无所适从。纯粹的哑对象因为不能完成更多的逻辑处理,所以当然需要更多的被当作参数传递给处理对象了。

#7楼    回复  引用  查看    

2006-09-28 08:42 by overred      
分开---->裸体
挂着---->比基尼
都很sexy


#8楼    回复  引用  查看    

2006-09-28 08:55 by 壮志      
楼上的很搞

#9楼    回复  引用  查看    

2006-09-28 09:12 by henry      
即使是将BLL和Model就是合而为一,也要看合并的方式。
如果Model职责不变的情况下合和不合并没有多大的区别。
我比较喜欢PetShop的方式的Model,因为职责很明确用于数据的收集和输出。
如果Model带有过多的责职,给人的感觉有点怪;虽然Model带有行为职责很方便,但从使用角度来说觉得有点不安全。

#10楼    回复  引用  查看    

2006-09-28 09:28 by aspnetx      
@overred
想象力...
佩服

#11楼    回复  引用  查看    

2006-09-28 09:36 by WaitU      
分开,
BLL中METHOD的代码有的多大NK行,合并的话更是不堪。。

#12楼    回复  引用  查看    

2006-09-28 09:37 by 老燕      
我的看法:Model集合是业务实体层,分离的原因是更于实体变更而不影响其它层

#13楼    回复  引用  查看    

2006-09-28 09:51 by 维生素C.NET      
我不赞成分开。对象之间的关系要有规则才可以,才能保持不乱,那就是永远都是消费者调用生产者,同时,每个对象都可以扮演任何一种角色,但是对于某个特定的与它有关系的对象,它的指责也是确定的。

消费者去call生产者,就是去调用生产者的方法,反过来要用事件处理,用委托。这样才能保持逻辑清晰。

而把property和methed分开后,只是引入了一个“第三者”,如果不是help类,这样的东西表面看上去会比较清晰,但是它什么都能做,权力大到难以控制的时候,系统的整体把握性也变差了。

#14楼    回复  引用  查看    

2006-09-28 10:02 by 木野狐[匿名]      
我觉得并起来比较好。类似于 ActiveRecord 模式,逻辑比较清晰,也易于编写。

#15楼    回复  引用  查看    

2006-09-28 10:22 by GerryJiang      
看来博客园也有必要大规模的对几种领域模型进行一次讨论了

#16楼    回复  引用  查看    

2006-09-28 12:44 by 无赖.net      
我以前做的项目都是合起来的,现在决定分开(分开后也确实不那么OO,不过我个人觉得OO在管理代码方面作用很大,所以方便管理代码很重要),分开property和 methed之后会感觉BLL(业务逻辑)非常清晰(还有个原因是:SQLServerDAL把sql语句也分开了吧),几乎是完全的逻辑(if else),准备彻底体验分开后的好与坏。:)

#17楼    回复  引用  查看    

2006-09-28 12:51 by overred      
@壮志
@aspnetx

我们经常这样叫的
话又说回来,感觉分不分确实不应细纠
夫妻恩恩爱爱 绵绵缠缠 何必要分呢
这是我个人的感情色彩

#18楼    回复  引用  查看    

2006-09-28 14:03 by 鸡哥哥      
要看不同的情况呢?有时候domain ojbect中有逻辑是很可笑的,比如支票这类名词性的东东。

#19楼    回复  引用  查看    

2006-09-28 16:22 by overred      
@鸡哥哥
楼上大哥的Name弓虽

#20楼    回复  引用  查看    

2006-09-29 12:53 by yinh      
这些东西,去javaeye上看看java方面的讨论就ok了

#21楼    回复  引用    

2007-01-29 10:41 by 怪怪 [未注册用户]
@Dflying Chen
楼主不要受了他引用的这个帖子的骗....,这些东西了解一下是好的,多搞无意。
个人认为Java这种讨论无利于编码生产力的进步,总有一天会停止。你看那帮哥们互相打起来厉害,什么你不够OO我不够OO的,GOF写出来的程序按他们的标准也未必够OO,马丁如果穿个普通人的马甲估计也会被他们骂。可一上了神坛,他们就把人家的话当金科玉律了。

关键是到什么地步够的问题。这帮人觉得搞这些高级,这些不过是对基础的重新组织,问题在世界上还有更高级的学问,就是完成一件事到底需要什么元素(比如OO、比如设计模式)、这个元素需要到什么程度。这种判断有时候甚至是直觉,决不是成天沉迷在模式之类的中就可以得到的。人的精力有限...,比如,Java编写的无论大型、小型项目、软件里,能有几个称得上伟大、经典的?当然除非你说处处体现了OO思想就是经典。问题是项目和软件的衡量标准不是这个。劲儿还是用在关键的地方比较好。

#22楼    回复  引用    

2007-09-07 10:40 by dianshijin [未注册用户]
学习 ^_^