将dbml用于linq2sql查询有哪些优缺点？

Question

我目前正在阅读Pro Asp.Net MVC，他们正在手工构建所有linq2sql实体类，并使用linq映射属性进行映射。然而，我看到的所有其他人（来自谷歌搜索）谈论linq 2 sql似乎都在使用视觉设计师来构建他们所有的实体。哪个是构建l2s实体的首选方法，每个实体的优点/缺点是什么？

到目前为止，我注意到的唯一区别是，在使用可视化设计器时我似乎无法进行继承映射，尽管MSDN说我应该能够这样做，因此我可能只是在VS 2010的界面中忽略它。但是，我不太确定我应该使用继承，因为当我不需要子表数据时，技术上可以添加额外的连接。

作为PS，l2s不会对我的架构进行任何修改，我将手动生成架构更改，然后在linq2sql中复制它们。

谢谢，

Answer 1

我们一直使用设计师。它确实引入了一个额外的步骤，每次你对模式进行更改时，你需要再次将表导入设计器，但我认为，如果你绕过desginer，那么与你需要编写的代码量相比，effrot会相形见绌。

另请注意，设计器创建了部分类，您可以为包含其他实现细节的分部类创建其他文件。这样，当表格在设计器中被引用时，它就会留下额外的代码。我们这样做是为了向类中添加许多辅助函数，并且还提供覆盖原始整数FK字段的严格类型枚举属性。

确实很难完成继承，但我认为如果你需要那种数据层，L2S可能不是最好的解决方案。我更喜欢保持我的数据层干净简单，只需使用L2S来获取数据，然后在业务层中使用更复杂的逻辑。如果我们确实需要在数据层中执行对象继承之类的操作，我可能会探索更先进和更复杂的技术，如EF

Answer 2

我们使用L2S构建了整个应用程序框架后端。我开发了大部分内容。我开始使用DBML设计师，但我很快意识到这是一个皇家的痛苦。每次架构更改都需要更改设计器中的表。此外，设计人员创建的实体都填充在单个类文件中，并且没有我想要的所有功能，例如支持M2M关系等等。所以，在我意识到自己想要一个更好的方式之前不久就已经过了。

我最终编写了自己的代码生成器，以我想要的方式生成L2S实体，并且它还生成了一组在应用程序层中使用的“轻量级”实体。这些没有任何L2S管道。代码生成器直接从目标数据库创建所有这些实体和其他代码。不再是DBML！

这对我们来说非常有效，我们的实体正是我们想要的方式，并且每次我们的数据库架构发生变化时都会自动生成。