我喜欢LINQ to SQL，但看起来它生成的类与它们存储的数据库紧密耦合，这看起来像是一件坏事。
例如，使用ye olde Northwind数据库，如果我使用Products表创建dbml，a Product 生成了类。我可以在任何其他层使用此类，这一切都很好，但如果我决定使用普通的旧ADO.NET（或交换机数据库），我将不得不重新创建 Product 课堂，以及其他所有“模特”。
有没有解决的办法？或者单独创建对象模型，然后将表映射到它们？我已经玩过提供的各种映射类，但还没有找到满意的答案。
所有这些答案，没有链接！也许我可以帮忙：
我已经在这个困难中度过了几次，最后我在上一个项目中做的是使用接口作为在解决方案中所有不同项目之间共享的契约，并让部分类实现它。
[Table(Name="Products")]
public partial class Product: IProduct { }
是的，遗憾的是，它需要一些反思才能使其适用于POCO实施。
最后，如果你真正关心它，我会选择NHibernate（我也不喜欢它），这正是Garry Shulter所描述的。
希望有所帮助！
我的团队最近与这个问题进行了斗争。我真的很想保持“持久性无知”，这意味着域对象可以创建为普通的旧C＃对象，而不必强制从某个基类继承或者用一堆属性使类混乱。就像你说的那样，我们希望能够独立于业务模型修改持久层。
最后，如果你想要持久性无知，我们决定LINQ不是要走的路。我们最终编写了太多的映射代码来在LINQ层和业务层之间进行转换。当我们开始编写一堆基于反射的代码来尝试自动执行这些映射时，我们意识到我们正在滑下兔子洞，几乎没有显示它。
如果持久性无知对你很重要，你可能会更好地使用像NHIbernate这样的完整ORM。
Linq to SQL（或EF）是 不 关于持久性 - 无知。它是关于数据的对象视图。
NHibernate是你可能正在寻找的持久性 - 无知的ORM。
我最近通过自己创建POCO并手动为数据库创建XML映射文件来实现这一目标。它需要一些手动工作，但它会产生预期的效果。
这是一个 博客文章我发现有用 让你入门
哦，嘿，我想我在观看时找到了解决方法 Rob Conery在ASP.NET MVC上的截屏视频。诀窍是 select进入LINQ to SQL查询中的对象。
public IQueryable<LinqExample.Core.Person> GetAll() {
var people = from pe in this.db.Persons
select new Person {
Id = pe.id,
FirstName = pe.fname,
LastName = pe.lname,
Reports = this.GetReports(pe.id)
};
return people;
}
这个让你定义一个 Person 在您的代码中的其他地方。 我在博客上写了这篇文章 更深入。
Scott Hanselman做了一个关于asp.net DynamicData的屏幕，他使用了Linq To Sql类。虽然他没有解决这个问题，但我认为一般概念仍然可行。他的方法是创建一个单独的 局部 与该类同名的类， Product 在您的情况下，这是由dbml生成的。然后你应该总是有一个 Product 存在于LINQ生成之外的类，只是“扩展”它所做的事情。
只需将生成的代码复制到您自己的类中，然后关闭代码生成。神奇的是属性而不是其他任何东西。
或者，您可以编写自己的没有属性的纯CLR对象，并使用外部XML映射文件来描述对象与数据库之间的关系。可以在MSDN上的LINQ to SQL文档中找到更多信息。