Question

我目前正在汽车经销商网站上工作，我一直在我的数据库中使用“车辆”模型。我一直在广泛使用具有FK关系的查找表，用于Color，Make，Model等。

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

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等一起使用。

我想我只是在问我采取的方法是否合理？欢呼声。

Answer 1

您所做的是从LINQ创建低级对象，然后在它们之上构建您自己的Business Objects（或View Model）。

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

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

使用Linq-to-Sql的查找表

1 个答案: