使用 Linq-to-Sql 查找表
我目前正在开发一个汽车经销商网站，并且我一直在数据库中开发“车辆”模型。我一直在广泛使用具有 FK 关系的查找表来处理颜色、品牌、型号等。
因此，基本版本可能类似于：
Vehicle {
Id
MakeId
ModelId
ColourId
Price
Year
Odometer
}
然后使用一个简单的 2 列查找表，例如颜色将有ColourId 列和 ColourText 列；没什么不寻常的。
这一切都很好，但是我发现当您开始使用查找表时，生成的 Linq-to-Sql 类变得更加复杂。为了获得颜色，我现在必须执行诸如 Vehicle.Colour.ColourText 之类的操作。添加新车辆需要查找所有各种表以确保值存在等。因此，我真的不想在应用程序代码的其余部分传递此 Linq-to-Sql 模型。
因此，我当前的方法实现了几种方法来将此 linq 模型转换为纯域模型，这几乎是一个相同的对象，但只是将 Id 字段替换为其实际文本值（字符串）。这一切都包含在存储库中，因此应用程序的其余部分只知道这些直接的“域”对象，而不是数据访问对象。如果应用程序需要插入新记录，我会将此域模型传递回存储库，然后存储库将其转换回 Linq-to-Sql 变体，确保所有查找值实际上都有效。
这是个好主意吗？我觉得做这个转换有点肮脏，它似乎违背了最初使用 Linq-to-Sql 的原因之一。话又说回来，我想将查找等内容传递给应用程序的其余部分的对象会更糟糕。这就是更成熟的 O/RM 得到更广泛使用的原因吗？
使用域对象而不是 L2S 对象还可以使 JSON 序列化更容易与 AJAX 等一起使用。
我想我只是想问我采取的方法是否合理？干杯。
I'm working on a car dealer website at the moment, and I've been working on a 'Vehicle' model in my database. I've been making extensive use of lookup tables with FK relationships for things like Colour, Make, Model etc.
So a basic version could be something like:
Vehicle {
Id
MakeId
ModelId
ColourId
Price
Year
Odometer
}
Which then uses a simple 2-column look-up table, for example Colour would have a ColourId column, and ColourText column; nothing unusual.
This is all good and well, however I've found my generated Linq-to-Sql classes become more complex when you start using look-up tables. To get the colour I now have to do things like Vehicle.Colour.ColourText. Adding new vehicles requires looking up all the various tables to ensure the values are there, etc. So I don't really want to be passing this Linq-to-Sql model around the rest of my application code.
So my current approach implements a couple of methods to convert this linq model into a pure domain model, which is nearly an identical object, but just replaces the Id fields with their actual textual values (strings). This is all wrapped up in a repository, so the rest of the app is only aware of these straight 'domain' objects, and not the data access objects. If the app needs to insert a new record, I pass this domain model back in to the repository, which then converts it back to the Linq-to-Sql variant, ensuring all the lookup values are in fact valid.
Is this a decent idea? I feel a little dirty doing this conversion, it seems to go against one of the reasons for using Linq-to-Sql in the first place. Then again, I guess it would be even worse passing around objects exposing look-ups and the like to the rest of the app. Is this why more fully-fledged O/RMs are more widely used?
Using the domain objects over the L2S ones also makes it easier for JSON serialisation for use with AJAX and the like too.
I guess I'm just asking if the approach I've taken is reasonable? Cheers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您所做的就是从 LINQ 创建低级对象，然后在它们之上构建您自己的业务对象（或视图模型）。
这没有什么问题：事实上，它可以帮助将应用程序与关系模型隔离开来，并将其更全面地引入对象领域。当人们构建 ViewModel 来绑定到 UI 时，您会看到显式完成此操作，ViewModel 实际上通过低级实体加载和保存。
缺点是需要更多编码。好处是您的对象集合实际上更好地反映了您的应用程序用例。我建议继续探索这条道路。也许看看这里可以帮助您：http: //blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
What you have done is created low level objects from LINQ and then built your own Business Objects (or View Model) on top of them.
There is nothing wrong with this: in fact, it can help isolate the application from the relational model and bring it more fully into the Object realm. You see this done explicitly when people build a ViewModel to bind to the UI, where the ViewModel actually loads and saves through the low level entities.
The downside is more coding. The upside is that your object collection actually reflects your application use-cases better. I recommend continuing to explore this avenue. Perhaps a look here help you along: http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx