我正在使用上述技术,并且遇到了我认为是我造成的设计问题。
我的数据库中有一个艺术品表,并且能够将艺术品(我现在将它们视为数字产品)添加到购物车 + CartLine 表中。我拥有的将艺术添加到画廊和用户帐户等的系统运行良好。
现在客户想要销售 T 恤、杯子和钢笔等“硬件产品”,因此我创建了一个“硬件产品”表。
现在我在两个表中有两种不同的产品类型。我在 HardwareProducts 表和 Artwork 表中使用 GUID 作为 PK。当客户将商品添加到购物车时,我将 GUID 存储在 CartItems 表的 ProductID 列中。
问题是当我通过 ORM 将 LineItem 对象带到前端时,数据库不知道要引用哪个表。
在 OOP 中,我可以看到如何拥有 Product 基类,然后是由它驱动的 DigitalProduct 类和 HardwareProduct 类,但是如何在 SQL Server 和 Entity Framework 中对此进行建模,或者还有其他方法吗?
编辑:
由于以下评论,这就是我目前在测试应用程序中所拥有的内容。为我做到这一点的技巧是利用类似于 Stephane 指出的 ORM。它引导我到 this优秀的文章。
alt text http://img411.imageshack.us/img411/3568/32654541.jpg
允许:
int prodCount = _entities.Product.OfType<ArtWork>().Count();
IEnumerable<LineItem> lineItem = _entities.LineItem.Include("Product");
int artWorkCount = lineItem.Select(p => p.Product).OfType<ArtWork>().Count();
ArtWork prod = new ArtWork();
prod.Price = 2;
prod.ProductName = "atlast";
prod.Downloads = 3;
prod.GalleryID = 1;
_entities.AddToProduct(prod);
_entities.SaveChanges();
我即将将其集成到我的主要解决方案中,如果我有更多发现,我会通知您,但我认为一切看起来都不错。注意:看来提到的 Type 列最终实际上并不需要,这真是一个惊喜,这要归功于 ORM 提供的干净解决方案。谢谢大家
最佳答案
这是糟糕的数据库设计。您应该在基表中包含每个产品的 ID 和共同功能,并在扩展表中包含针对不同类型产品的特定功能。
示例:
产品:ID、描述、单价、产品类型(艺术品或硬件)
图稿:产品 ID、年份、尺寸
HardwareProduct:ProductID,其他功能。
在购物车中您存储产品 ID 和数量。
由于可能有更多的产品类别,因此您应该考虑存储特定于产品类别的参数的表和存储其值的另一个表。
以及对您的 OOP 解决方案的评论。一开始拥有 DigitalProduct 和 HardwareProduct 类可能会很有趣,但是商店中的商品可能具有如此多的不同功能,以至于您将无法将其转换为不同的类。笔有颜色,T恤有尺寸,杯子有容量,所以当你开始思考时,杯子和T恤之间的区别更大,然后是艺术品和T恤之间的区别。那么为什么马克杯与 T 恤和艺术品放在同一个地方呢?
您绝对应该查看一些开源电子商务解决方案并了解它是如何完成的。您的客户可能想开始销售其他类型的产品,您必须考虑设计更通用的解决方案。添加其他类效率不高。
关于SQL、MVC、 Entity Framework ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2708288/