|
这个主题共有 5 回复 ／ 1 页 [
]
|
|
|
|
|
|
领域模型VS事务脚本
|
发表: 2008年05月15日 12:57
|
回复
|
|
在CSDN里头看到了关于“领域模型，事务脚本”的一点讨论：
http://topic.csdn.net/t/20041007/11/3430605.html#
得知原来“事务脚本”同样用类，却并不是真正的面像对象：很多人也在用类,也在使用模式,但是他们的思维一样是面向过程的,因为他们的世界中除了过程就不存在任何东西了
它们俩如何来区分呢？
其实还是面向过程与面向对象的分别：
事务脚本：围绕功能，以功能为中心。
领域模型：描述领域类，以类之间的协作完成所需功能。
-----------------------
发表一下看法。
[该贴被xinying_ge于2008-05-15 13:42修改过]
|
|
|
|
|
|
回复:领域模型VS事务脚本
|
发表: 2008年05月15日 14:57
|
回复
|
|
A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken out into sub-procedures. Each Transaction Script is a public method on a class.
A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, which may be as large as a corporation, or as small as a single line on an order.
--------from<<POEEA>>
[该贴被xinying_ge于2008-05-15 15:00修改过]
|
|
|
|
|
|
回复:领域模型VS事务脚本
|
发表: 2008年05月16日 08:49
|
回复
|
|
所谓事务脚本，MartinFowler定义是：将所有逻辑组织在一个单一过程，进行数据库直接调用，
每笔交易（业务请求）都有自己的事务脚本，并且是一个类的公开方法。
A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken out into sub-procedures. Each Transaction Script is a public method on a class.
所谓领域模型，是一系列相互关联的对象，每个对象代表一定意义的独立体，既可以一起以一种大规模
方式协作；也可以小到以单线方式运行 。
A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, which may be as large as a corporation, or as small as a single line on an order
领域模型和事务脚本其实代表两种不同思维，这个我已经反复说明，因为思维不同，转变就很难，就像换一个人，你说多难。
事务脚本总体来说：就像直奔主题，平铺直叙，就功能谈功能，直接没有回旋余地；给人感觉好像肚子里就那么点货而领域模型则象是文人骚客，上了一个档次，会使用美妙表达方式，有余地。
比如唐诗：清明时节雨纷纷，路上行人欲断魂；借问酒家何处有，牧童遥指杏花村；这是领域模型描述方式，如果采取事务脚本方式就是：清明我很伤心，伤心要喝酒。
从教育背景来看：事务脚本只要脑子聪明一点就会写，所以，过去做软件的很多都不是学软件的，因为学和不学一个样，学的内容不对啊，学的内容应该是什么呢？就是对象，就是领域模型，学了这个以后，你的思维就上一个层次，曾经沧海难为水，你经过看山是山，到看山不是山，最后是：看山还是山，这样螺旋上升，否定之否定痛苦涅磐后，你就是一个专业的程序员，就像是受过教育的软件文人了，之前你是软件土人。
现在有道友为我打抱不平：为什么jdon里语言攻击banq的人哪么多，其实攻击人身的都删除了，现在剩余的都是正常讨论。多谢他们，这种现象其实有背后客观原因：
我一直也在思考为什么我抛出一个我认为正常的观点引起那么多争议，主要还是思维不同，OO思维重点和传统过程式思维不同，这就像伊斯兰和基督到今天还是争论和战争。
由于我们传统软件教育以数学数据过程式思维为主，过去，在各种媒体中，都是过程思维的人以口水淹死人。如：软件最厉害是算法（软件是为需求服务的，需求当然最重要，能把需求提炼出来当然厉害，算法属于需求提炼，只业务建模一种，不属于软件技术本身）；多读读数学吧（相反，我奉劝大家多读读文学诗歌，看看古人诗歌对自然界深刻优美的提炼，多精炼美妙啊，你有这个抽象化简能力吗？多读读哲学）。
我不是否定功能主义过程式思维，而是提倡应该在完成功能目标基础上，看得更远一些，将来的维护性和拓展性应该考虑，实际一点至少少一些BUG，为什么很多系统BUG就像虱子永远抓不完，就是过程式思维导致，JiveJdon3的90%时间我花在设计开发，10%在调试，调试通过过，就上线运行，到现在没有发现大BUG，小BUG近一年，不超过10个，这样系统不是在讲神话，也不是在梦想，实际就在那里，关键你相信与否？或者能够去做，所以，我有时到客户公司培训咨询，常常我亲自操刀证明给他们看，最后结果，我不想让他们认同我个人的技术，而是认同我掌握的方法，这就是OO。
OO在软件到处存在，有人可能觉得J2ME嵌入式手机不需要，其实越是这样资源比较有限，越是讲究设计，最近重构一个手机J2ME客户端，设计者将各种重要的初始类型静态化，或者进行共享，最后，可能都搞不清楚，运行时刻，哪些行为改变了这些字段值，其实使用对象对他们进行分类，重要状态的就共享，否则就作为参数，这样不会占据宝贵的内存，也不会导致难以捉摸的BUG。
又比如：手机有各种型号，不同手机有不同特殊条件，比如w600因为音乐手机，对线程管理严格，如何实现一套Java源码跑遍所有手机，针对不同手机需要不停的频繁修改完善，如果程序不是OO设计，简直是不可能的事，所以很多手机Java产品针对不同手机做不同版本，这些都是极大浪费和无知。
有人觉得网络游戏软件不需要，我看到已经有人提出做游戏不是做产品，而是做服务，既然，是做服务，那么你就会一直服务下去，市场需要什么就马上提供什么服务，谁提供更快更好服务，就能制胜，这种高质量服务就是依靠软件的伸缩性 可拓展性。
[该贴被banq于2008-05-16 16:30修改过]
[该贴被admin于2008-05-27 20:08修改过]
|
|
|
|
|
|
re:领域模型VS事务脚本
|
发表: 2008年05月18日 01:25
|
回复
|
|
|
|
|
|
|
|
回复:re:领域模型VS事务脚本
|
发表: 2008年05月18日 12:12
|
回复
|
|
|
|
|
|
|
|
回复:领域模型VS事务脚本
|
发表: 2008年05月23日 14:57
|
回复
|
|
|
|
|
|
注册
登陆
上一主题
下一主题
