3

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

  1. sqlmetal
  2. 对象关系设计器
  3. 手码

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

编辑：

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

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

2 回答 2

4

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

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

于 2011-07-13T03:45:22.303 回答
0

即使 Designer 生成的类很乱，这对你有什么影响？

我敢说，绝对不需要打开任何一个设计文件。

如果您需要扩展模型中定义的任何实体，它们都是部分类，因此您可以创建自己的同名部分类并实现您的东西......

当我使用 L2S 时，我只使用设计器。

于 2011-07-13T00:39:28.097 回答