|
这个主题共有 22 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
|
|
|
订单模型设计疑问
|
发表: 2007年08月10日 17:50
|
回复
|
|
各位大侠大家好。我想设计一个订单模型。现在设计如图所示：
Torders代表的是订单；TorderItem代表的是订单明细；Tparts代表的是商品；Tprice代表的是价格；Tsupplier代表的是供应商。请大家指点一下。
哈，如果有哪位大侠有好的模型请提供一下，让小弟学习学习。
[该贴被sxdthonda于2007年08月16日 15:13修改过]
|
|
|
|
|
|
回复:订单模型设计疑问
|
发表: 2007年08月15日 12:28
|
回复
|
|
设计不错啊。
你需要其他给你show他们的模型？是展示他们漂亮的模型图呢（可能五颜六色）？还是其他什么？
模型是根据业务需要来设计的，你没有贴出你的业务需求，而只是告诉我们结果，这就很难了，就象1+1=2，你只告诉我们2的结果，并且用彩笔画了好看的2字，意义不太大噢。
UML图就象AutoCAD图一样，会画AutoCAD的不一定是建筑师。关键是掌握设计思想。
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月15日 12:44
|
回复
|
|
多谢彭老师:)
我是在学习O/R时想自已做一个简单的库存管理软件练练手。基本业务流程是：
操作员下订单，选择供应商，同时录入需要订货的明细。这个可以使用刚开始的类模型。
但我想，当到货入库时，该怎么操作呢？（业务流程是：当到货后，首先点到货数量，然后根据到货数量，做一个入库单，当然还要更新库存数量等信息）。但在些，入库单这个怎么处理呢？想了好久都没办法。
订货单，入库单，以后还要能进行一查询。
在下疑问是：
再设计一个入库单及入库明细类呢，还是把现在的Torder类增加一些属性，同时表示订货、入库呢？
请各位请辈指点一下。
|
|
|
|
|
|
回复:re:订单模型设计疑问
|
发表: 2007年08月15日 12:52
|
回复
|
|
>再设计一个入库单及入库明细类呢，还是把现在的Torder类增加一些属性，同时表示订货、入库呢？
这是问题关键，我们曾经讨论过：一个事物必然要包括一个约束问题，只要它符合一个约束，就可以定义它为类/对象，也就是说，一个对象中属性必须是明确标明它的特征，是一种约束。
Torder是订单对象，很显然入库不属于订单的内在属性，不应该被划入订单对象，而应该重新设计一个对象“库单”（可以设计有入库单/出库单两种子类）。
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月15日 14:23
|
回复
|
|
|
|
|
|
|
|
回复:re:订单模型设计疑问
|
发表: 2007年08月15日 14:30
|
回复
|
|
>一句话点醒梦中人
其实对象设计一点不深奥，它就是我们日常生活的知识，只不过我们原先被所谓专业知识（如数据库分析设计）蒙蔽双眼，还有多少人没有醒悟呢。
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月15日 18:24
|
回复
|
|
TPrice 有必要存在吗？
我觉得应该是 TPart 的一个属性
TOrder 也没有存在的必要吧，有一个 出库Order 和 入库Order 就可以了。
甚至我认为出库，入库成为一个订单的属性更合理。
不然，如果订单分为经理签字和经理不签字2种情况，也设计成2个类？
[该贴被yananay于2007年08月15日 18:29修改过]
[该贴被yananay于2007年08月16日 09:16修改过]
|
|
|
|
|
|
回复:re:订单模型设计疑问
|
发表: 2007年08月16日 14:48
|
回复
|
|
模型建立有不同意见是最好的，能够加深我们对业务的认识。
如果TPrice 不是一个很重要的事情，确实应该纳入Torder一个属性，我同意这点。
>我认为出库，入库成为一个订单的属性更合理
可能楼上没有对业务流程有一个熟悉，订单有了以后，工厂根据订单生产出产品货物，产品货物才有出库和入库的概念，因为必须首先放到仓库中保存。
领域建模就应该象这样通过不断讨论加深每个参与者对业务的熟悉。不断迭代，最后找到接近事物本质的模型出来。
最近帮助一家公司查看他们软件项目的招标书和设计书，基本就是将数据表结构字段列出来，然后，大谈Spring Hibernate等框架，这显然是一种畸形的设计书，完全不是OO的，高质量的设计书应该是大量篇幅谈论这个项目系统的对象模型设计，如上述讨论设计过程总结。
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月16日 15:16
|
回复
|
|
原来是这样。。呵呵
那么出库入库因该是货物的属性了。
不过还是提醒楼主，刚刚学习从业务领域进行分析的时候，
很容易陷入对象的陷阱，例如你设计的 TPrice。
切忌，你是为了理清业务而使用对象，
而不是为了对象而使用对象。
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月16日 15:30
|
回复
|
|
>可能楼上没有对业务流程有一个熟悉，订单有了以后，工厂根据订单生产出产品货物，产品货物才有出库和入库的概念，因为必须首先放到仓库中保存。
那将出库、入库作为Tparts商品的属性呢？
|
|
|
|
|
|
回复:re:订单模型设计疑问
|
发表: 2007年08月16日 15:48
|
回复
|
|
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月16日 16:52
|
回复
|
|
|
太好了，大家的讨论太精彩了，我又学到不少知识。呵呵，已经将Tprice全部归到TParts中了。
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月22日 17:51
|
回复
|
|
仔细分析一下楼主的业务需求,我想指出这个模型中有以下几个地方不是很正确,或与常规的定单模型相背.
1 模型中TOrders 与 TSupplier之间应没有直接关系(如有也不是一对一的关系)
与定单TOrders关联的应该是TOrderItem,与TOrderItem关联的是TParts,与TParts关联的才是TSupplier.
举个例子,我们要下定单买件衣服,首先我们不应去选择一个供应商(比如选择美国波音公司),之后再去选择这个供应商的商品,因为这个供应商可能并没有我们需要的商品.
当然你可能说我对这个供应商很熟悉并了解他有什么商品,但这仍不是一个好的设计.试想当你需要变更定单中某一个商品时(如不采购波音的飞机,换成空客的飞机),你将需要同时修改定单(具体应该是定单名细),以及维据与供应商的关系.在实际业务中这样的模型是浑沌的开始．
2 楼主的Use case并不适合应用定单模型来设计
我想用＂采购计划＂或＂采购模型＂也许更能表达楼主的业务需求．我们知道 只有在＂卖＂的一方才存在＂定单模型＂，＂买＂方只有采购计划．
根本原因是误用了模型，所以再讨论把＂出库／入库＂置入TOrders或TParts中，这已不是妥不妥的问题了，很显然这是一个不好的设计，将与对象毫不相关的属性放入到对象中．另外强调一下，不要把＂出库／入库＂作为商品(TParts)的属性，就如＂在哪里＂能作为＂人＂的一个属性吗，否则＂人＂会有无数多的属性．
以上是我的一点看法，欢迎大家指正
|
|
|
|
|
|
re:订单模型设计疑问
|
发表: 2007年08月27日 12:33
|
回复
|
|
呵呵,上周在北京整整培训了5天!
chen8251 ,你的分析很有理.我是初学O/R自己想设计一个模型.非常感谢大家的宝贵意见.
|
|
|
|
|
|
回复:re:订单模型设计疑问
|
发表: 2007年09月03日 20:37
|
回复
|
|
|
|
|
|
|
|
这个主题有 22 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
