我目前正在阅读 Pro Asp.Net MVC，他们正在手动构建所有 linq2sql 实体类，并将它们与 linq 映射属性进行映射。但是，我看到的其他所有人（来自谷歌搜索）谈论 linq 2 sql 似乎都在使用可视化设计器来构建他们的所有实体。哪种是构建 l2s 实体的首选方式，每种方式的优缺点是什么？
到目前为止，我注意到的唯一区别是，在使用可视化设计器时，我似乎无法进行继承映射，尽管 MSDN 说我应该能够做到，所以我可能只是在 VS 2010 的界面中遗漏了它。但是，我不太确定是否应该使用继承，因为当我不需要子表数据时，从技术上讲，这可能会添加额外的连接。
作为 PS，l2s 不会对我的架构进行任何修改，我将手动生成架构更改，然后在 linq2sql 中复制它们。
谢谢，
我们一直使用设计师。它确实引入了一个额外的步骤，每次对架构进行更改时，您都需要再次将表导入设计器，但我认为与绕过设计器所需编写的代码量相比，这种 effrot 相形见绌。
另请注意，设计器创建了部分类，您可以为部分类创建一个包含额外实现细节的附加文件。这样，当表在设计器中被引用时，它只剩下额外的代码。我们这样做是为了向类中添加许多辅助函数，并提供覆盖原始整数 FK 字段的严格类型的枚举属性。
继承确实很难很好地完成，但我认为如果你需要那种数据层，L2S 可能不是最好的解决方案。我更喜欢让我的数据层保持干净和简单，只是使用 L2S 来获取数据，然后在业务层中进行更复杂的逻辑。如果我们真的需要在我们的数据层做对象继承之类的事情，我可能会探索像 EF 这样更高级和更复杂的技术
我们已经使用 L2S 构建了整个应用程序框架后端。我开发了大部分。我开始使用 DBML 设计器，但我很快意识到这是一种痛苦。每次架构更改都需要更改设计器中的表。另外，设计师创建的实体都被塞进了一个类文件，并且没有我想要的所有功能，比如对 M2M 关系的支持等等。所以，没过多久我就意识到我想要一个更好的方法。
我最终编写了自己的代码生成器，以我想要的方式生成 L2S 实体，并且它还生成了在应用程序层中使用的一组“轻量级”实体。这些没有任何 L2S 管道。代码生成器直接从目标数据库创建所有这些实体和其他代码。没有更多的 DBML！
这对我们来说效果很好，我们的实体正是我们想要的方式，并且每次我们的数据库模式更改时都会自动生成。