我正在为一个应用程序开发一个新的域模型，该模型将对内置的项目进行订单处理（好吧，无论如何也要保持简单）。我有一个类“VendorItem”，表示可以订购的项目。最初“Order”类将有一个与之关联的VendorItem列表，但到目前为止我遇到过它的问题。
假设系统已经创建了一段时间的订单就好了。有一天，用户出现并决定供应商已经改变了价格或其他一些细节，如包装尺寸。我不希望以前的订单受到这种改变的影响。
第一次洗时，我打算创建一个“OrderLine”类，它基本上是“VendorItem”类的副本，但是在OO意义上感觉（气味？）错误。
有没有更好的方法来重构这个，所以我没有域模型中的类和信息的副本？
答案 0 :(得分：1)
我发现首先描述你所知道的关于物品的所有内容要容易得多，而不是作为类。然后找出信息层次结构，然后找出如何用类建模。
例如： 商品是您从一个或多个供应商处购买的产品，通常由UPC（通用产品代码 - 注册的条形码）定义。
供应商通常也有一个内部ID号，通常称为供应商料号（VIN）。
物品可以有不同的尺寸和颜色，都有相同的UPC - 但不同的VIN可能有不同的成本：
T-Shirt UPC 9055540022
VIN: 40001 - Large, White - $5.00
VIN: 40002 - Small, White - $4.00
VIN: 40003 - Large, Green - $5.00
etc.
这些物品/ VIN的成本会随着时间的推移而变化。
订单是指在特定时间点的商品清单及其成本，因此您的订单信息需要包含成本以及订单中商品的任何其他可更改信息。
因此，如果项目UPC位于信息层次结构的顶部：
Item - 1 record per item - Descriptive info, UPC
Vendor - 1 record per vendor - Vendor info
VendorItemVin - 1 record per Vendor/Item/VIN - Vendor specific info, size/color/cost etc.
然后你可以知道数据库表应该是什么样的，然后计算出类。
答案 1 :(得分：0)
过去，我创建了“Variation”类。 VendorItem包含“变体”变体可以是T恤尺寸或内衣的味道。每个Variation都有自己的价格，所以你可以让巧克力内裤比草莓更贵。 OrderLine类具有对订单，变化，数量和价格的引用。您可以在OrderLine中保留价格，以便以后可以更改变体的价格而不会影响审核程序。然后，您只需添加变体并将旧变体设置为“InActive”，而不是编辑现有项目
我是否对家族企业说了太多话？
答案 2 :(得分：0)
IMO你应该主要由你的数据库来处理。您调用VendorItem的每个产品都有一个PK以及一个有效的开始（null不允许）和有效的结束日期（可能为null以处理当前停止的当前状态）以及有关该项目的所有相关信息。
在您的订单表中，您应该有一个与0到多个订单ID相关的CustomerID，并且该记录包含当时销售的VendorItem的外键。
通过这种方式，您可以跟踪对产品系列所做的所有更改，并且可以轻松分析价格变化，描述更改等对销售的影响。
在您的代码中几乎没有什么会改变，除非在订购/查看项目过程中您从产品表中获取当前项目。
答案 3 :(得分：-1)
是的，你可以使用“样板”，好吧无论如何你的想法是你有一个物品代表你的物品，冰鞋或其他东西的“产品”，然后你有一些物品由一些定价对象或东西组成，foreach命令你让你分配一个定价对象，所以现在当你改变一个价格或类别的东西时，你只需要为你的Item对象分配一个新的价格对象（带有不同的args），这样你只有一个类代表每个对象您的商品和价格对象可以定义商品的价格和特征（表示可能随时间变化的属性）。在这种情况下，样板是Item，因为它有点像模板，它永远不会改变，你定制的是你的Price对象（在给出的例子中）