使用 Linq-to-Sql 查找表答案

【问题标题】：Look-up tables with Linq-to-Sql使用 Linq-to-Sql 查找表
【发布时间】：2010-11-20 19:27:40
【问题描述】：

我目前正在研究汽车经销商网站，并且一直在研究数据库中的“车辆”模型。我一直在广泛使用具有 FK 关系的查找表来查找颜色、品牌、型号等。

所以基本版本可能是这样的：

Vehicle {
    Id
    MakeId
    ModelId
    ColourId
    Price
    Year
    Odometer
}

然后使用简单的 2 列查找表，例如 Color 将具有 ColourId 列和 ColourText 列；没有什么不寻常的。

这一切都很好，但是当您开始使用查找表时，我发现生成的 Linq-to-Sql 类变得更加复杂。为了获得颜色，我现在必须执行 Vehicle.Colour.ColourText 之类的操作。添加新车辆需要查找所有各种表以确保值存在等。所以我真的不想在我的应用程序代码的其余部分传递这个 Linq-to-Sql 模型。

因此，我当前的方法实现了几种方法来将此 linq 模型转换为纯域模型，这几乎是一个相同的对象，但只是将 Id 字段替换为其实际的文本值（字符串）。这一切都包含在存储库中，因此应用程序的其余部分只知道这些直接的“域”对象，而不是数据访问对象。如果应用程序需要插入新记录，我会将这个域模型传回存储库，然后将其转换回 Linq-to-Sql 变体，确保所有查找值实际上都是有效的。

这是个好主意吗？我觉得做这个转换有点脏，这似乎违背了首先使用 Linq-to-Sql 的原因之一。再说一次，我想它会更糟糕地传递对象，将查找等暴露给应用程序的其余部分。这就是更成熟的 O/RM 得到更广泛使用的原因吗？

在 L2S 对象上使用域对象也使得 JSON 序列化更容易用于 AJAX 等。

我想我只是在问我采取的方法是否合理？干杯。

【问题讨论】：

标签： linq-to-sql data-access-layer

【解决方案1】：

您所做的是从 LINQ 创建低级对象，然后在它们之上构建您自己的业务对象（或视图模型）。

这并没有错：事实上，它可以帮助将应用程序与关系模型隔离开来，并将其更充分地带入对象领域。当人们构建 ViewModel 以绑定到 UI 时，您会明确地看到这一点，ViewModel 通过低级实体实际加载和保存。

缺点是更多的编码。好处是您的对象集合实际上更好地反映了您的应用程序用例。我建议继续探索这条途径。也许看看这里可以帮助你：http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx

【讨论】：