很赞同chen8251 的观点。
我们看楼主的订单其实是采购行为产生的订单，并不是要别人要买楼主的东西，而是楼主要下采购单去买别人的东西，我们一般把它称为订购单。

[该贴被javaxmler于2007年09月05日 12:43修改过]

>TPrice 有必要存在吗？
>我觉得应该是 TPart 的一个属性

我觉得Tprice是不是要作为一个属性取决于需求和你对Price的认识。
TPrice存在的话，设计可能更具扩展性。
Tprice可能要表示美元，可能是人民币；可能用中文大写显示也可能是阿拉伯数字；
还可能需要定制一些价格策略，比如打折、买二送一什么的。

比较认同terry6394的说法，我们的系统在价格方面也遇到了一些麻烦，就是当时没有考虑到这些。

1 模型中TOrders 与 TSupplier之间应没有直接关系(如有也不是一对一的关系)

我认为是有关联的，下采购单肯定要知道下给谁，而且不会同一张单下给不同的 Supplier。TOrders 与 TSupplier的关系是非常重要的，不能忽视。

>模型中TOrders 与 TSupplier之间应没有直接关系
当然应该有直接关系，是一种高聚合，如果一个订单没有订货单位能叫订单吗？恐怕是产品明细单了。

有个问题:当供应商改变他的名字后,客户再查询以前的订单,在现实的订单中显示的应该是供应商更新前的名字吧,而在计算机中查询以前的定单的时候,通过关联关系获取到的是更新后的名字(我想:名字是供应商的一个属性,名字的改变不会影响他本身作为一个实体存在,不会算做一个新实体吧),这个是否和现实有冲突呢?那这个时候该如何处理这种情况呢?我想不明白!
是不是该把供应商的名字拉出来做为订单的一个属性呢?还有价格变动也存在同样的情况,是不是该把所有会变动的元素,都作为订单的一个属性,然后再把订单和各个对象关联起来.那我觉的是不是有属性重复的感觉?

>这个是否和现实有冲突呢?那这个时候该如何处理这种情况呢?我想不明白!
你这个问题很好，不过你提的问题属于另外一种解决领域：记录跟踪，也就是说使用计算机对现实中订单等进行记录跟踪，这个可以参考MF的“分析模式”中的Account来解决。

我觉得Tprice不应该作为Tparts的关联对象或者属性，而应该作为TOrderItem的一个关联对象，因为商品的价格是会变的，同一种商品对于不同供应商可能价格不同，对于同一个供应商也有可能在不同的两次订购中（即两张订购单中）价格也不同，这里的价格应该是记录当次订购明细的商品即时价格，是订单明细的一个重要信息，这样也有利于以后跟踪商品的价格变化情况。商品对象Tparts即使要和价格对象关联也只能是一个默认价格，而不能作为本次订购单的价格。

这根本就是一个很简单的问题。非要把它讨论的很复杂，其实大家说的都没错。这就是面对对象的精髓？

不太同意chen8251的观点
1 模型中TOrders 与 TSupplier之间应没有直接关系(如有也不是一对一的关系)
与定单TOrders关联的应该是TOrderItem,与TOrderItem关联的是TParts,与TParts关联的才是TSupplier.

实际业务，一个订单应该对应一个供应商，否则将造成收货后付款的困难。而且，订单产生前应该确定供应商，因为还要确定价格和订货份额分配。