LINQ to SQL 生成的对象可以解耦吗? [英] Can LINQ to SQL generated objects be decoupled?
问题描述
我喜欢 LINQ to SQL，但它生成的类似乎与存储它们的数据库紧密耦合，这似乎是一件坏事.
I like LINQ to SQL, but it seems like the classes it generates are tightly coupled to the database they are stored in, which seems like a Bad Thing.
例如，使用 ye olde Northwind 数据库，如果我使用 Products 表创建 dbml，则会生成一个 Product 类.我可以在任何其他层使用这个类，这一切都很好，但是如果我决定我宁愿使用普通的旧 ADO.NET(或切换数据库)，我将不得不重新创建 Product 类，以及所有其他模型".
For example, using ye olde Northwind database, if I create the dbml with the Products table, a Product class is generated. I can use this class in any other tier, which is all well and good, but if I decide I'd rather use plain old ADO.NET (or switch databases), I'll have to recreate the Product class, along with every other "model."
有没有办法解决这个问题?或者分别创建对象模型，然后将表映射到它们?我已经尝试了提供的各种映射类，但还没有找到满意的答案.
Is there a way around this? Or to create your object models separately, and then have the tables mapped to them? I've played around with the various mapping classes provided, but haven't found a satisfactory answer yet.
推荐答案
所有这些答案都没有链接！也许我可以帮忙:
All these answers and no links! Maybe I can help:
我在这个困难中苦苦挣扎了几次，我最终在上一个项目中所做的是使用接口作为解决方案中所有不同项目之间共享的契约，并让部分类实现它.
I have languished through this difficulty a couple of times, what I ended up doing on my last project was using interfaces as the contract that's shared between all of the different projects in the solution, and having the partial classes implement it.
[Table(Name="Products")]
public partial class Product: IProduct { }
是的，不幸的是，它需要一些反射魔法才能使其适用于 POCO 实现.
And yes, unfortunately it took some reflection magic to make it work for the POCO implementation.
最后，如果你真的很关心它，我会选择 NHibernate(我也不喜欢它)，这正是 Garry Shulter 所描述的.
In the end, if you are truly concerned about it, I'd go with NHibernate (I don't really like it either), which does exactly what Garry Shulter seems to be describing.
希望有帮助！
这篇关于LINQ to SQL 生成的对象可以解耦吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
