linq - 如何为 LINQ to SQL 生成类？

Question

我正在为我的 mvc 3 项目使用 linq to sql。有几种方法可以生成域模态类文件。

1. 数据库
2. 对象关系设计师
3. 手写代码

我总是手工编写那些模型类文件。因为sqlmetal或者designer生成的文件比较乱。你怎么看？最好的方法是什么。

编辑:

我使用的是 MVC 3，而不是 2。也许我错了，但这就是我验证的方式。无论如何，我最终会编写所有这些类文件，那么使用工具生成它们有什么意义呢？？？

public class User
{ 
    [Required]
    public string Password { get; set; } 
    [Required, Compare("Password")] 
    public string ComparePassword { get; set; } 
}

Answer 1

我们在多个数据库(一台服务器)上有数百个表。我们进行表优先开发，将表拖到不同的 DBML 设计器文件中，每个文件位于不同的文件夹中，代表每个项目中的不同 namespace 。设计器文件被标记为不可编译，我们使用自定义构建的 T4 模板，该模板通过读取项目中的任何 DBML 文件来生成我们的代码。这让我们可以完全控制生成的代码，因此我们可以做一些事情，比如实现一个接口(interface)(IAuditable 是一个例子，我们有 CreatedBy、CreatedDate、ModifiedBy、ModifiedDate)。我们也可以通过这种方式将 System.ComponentModel.DataAnnotations 放在我们的 Linqed 对象上，而无需求助于 Buddy Classes。 .我们有第二个 T4 模板，负责从数据库中刷新 DBML，因此我们可以确保表具有 3 部分前缀 (db.schema.tbl)，因此我们不必删除并重新添加到设计师。 XML 只是根据读取数据库模式和更新 DBML 而更改。我们还为每个具有一些常见查询操作(如 GetByID())的 POCO 生成一个存储库/管理器对象，并且还处理提交和审计日志记录。这些管理器扩展了您需要针对每个表编写的所有自定义查询，并且它们拥有 DataContext。这种设计有时被称为“Mommy-may-I?”方法，其中链接到表的对象必须要求其管理器为它做所有事情。

我发现这是一种非常灵活的 L2S 方式，它使我们的后端开发变得轻而易举，因此我们可以将重点放在用户体验上。唯一的缺点是，如果我们跨命名空间进行关联，您必须自己手动将它们添加到部分类中，否则您必须将该外部表添加到另一个 DBML 才能绘制关联。这实际上并不是一件坏事，足以让我们真正考虑命名空间的特殊性并减少多余的命名空间。以这种方式使用 T4 是开发 DRY 的好方法(不要重复你自己)。表定义是您唯一需要更改结构的地方，它会全部传播。验证在一个地方进行，即 POCO。查询集中在一个地方，经理。如果您想做类似的事情，here's a good place to start .