如何为 LINQ to SQL 生成类？
我正在为我的 mvc 3 项目使用 linq to sql。有多种方法可以生成域模态类文件。
- sqlmetal
- 对象关系设计器
- 手工代码
我总是手工编写那些模型类文件。因为sqlmetal或者designer生成的文件比较乱。你的意见是什么？最好的方法是什么。
编辑：
我使用的是 MVC 3，而不是 2。也许我错了，但这就是我验证的方式。无论如何，我最终都会编写所有这些类文件，那么使用工具来生成它们有什么意义？？？
public class User
{
[Required]
public string Password { get; set; }
[Required, Compare("Password")]
public string ComparePassword { get; set; }
}
I am using linq to sql for my mvc 3 project. There are several ways to generate domain modal class files.
- sqlmetal
- Object Relational Designer
- hand code
I always hand code those model class files. because files generated by sqlmetal or designer are messy. whats your opinion? whats the best way to do it.
EDIT:
I am using MVC 3, not 2. Maybe I am wrong, but this is how I validate. I gonna end up writing all those class files anyway, so whats the point to use tools to generate them???
public class User
{
[Required]
public string Password { get; set; }
[Required, Compare("Password")]
public string ComparePassword { get; set; }
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们在多个数据库（一台服务器）中有数百个表。我们首先进行表开发，将表拖到不同的 DBML 设计器文件中，每个文件位于代表每个项目中不同名称空间的不同文件夹中。设计器文件被标记为不编译，我们使用自定义构建的 T4 模板，该模板通过读取项目中的任何 DBML 文件来生成我们的代码。这让我们可以完全控制生成的代码，因此我们可以执行诸如实现接口之类的操作（IAuditable 是一个示例，其中我们有 CreatedBy、CreatedDate、ModifiedBy、ModifiedDate）。我们也可以通过这种方式将 System.ComponentModel.DataAnnotations 放在 Linqed 对象上，而无需求助于 好友课程。我们有第二个 T4 模板，负责从数据库刷新 DBML，因此我们可以确保表具有 3 部分前缀 (db.schema.tbl)，因此我们不必删除并重新添加到设计师。 XML 只是根据读取数据库模式和更新 DBML 进行更改。我们还为每个 POCO 生成一个存储库/管理器对象，该对象具有一些常见的查询操作（例如 GetByID()），并且还处理提交和审核日志记录。这些管理器可以通过您需要针对每个表编写的所有自定义查询进行扩展，并且它们拥有 DataContext。这种设计有时被称为“妈妈可以吗？”方法，Linqed 到表的对象必须要求其管理器为它做所有事情。
我发现这是一种非常通用且灵活的 L2S 方式，它使我们的后端开发变得轻而易举，这样我们就可以将重点放在用户体验上。唯一的缺点是，如果我们跨命名空间进行关联，您必须自己手动将它们添加到分部类中，否则您必须将该外部表添加到另一个 DBML 中才能绘制关联。这实际上并不是一件坏事，因为它让我们真正考虑命名空间的特殊性并减少额外的命名空间。以这种方式使用 T4 是开发 DRY 的好方法（不要重复自己）。表定义是唯一需要更改结构的地方，并且所有结构都会传播。验证在一个地方进行，即 POCO。查询集中在一个地方，即经理。如果您想做类似的事情，这里是一个很好的起点。
We have hundreds of tables across multiple databases (one server). We do table first development, drag the tables onto different DBML designer files each in different folders representing different namespaces within each project. The designer files are marked not to compile, and we use a custom built T4 template that generates our code by reading from whatever DBML files are in the project. This lets us have full control of the code that's generated, so we can do things like implement an interface (IAuditable is one example where we have CreatedBy, CreatedDate, ModifiedBy, ModifiedDate). We can also put System.ComponentModel.DataAnnotations on our Linqed objects this way too without resorting to Buddy Classes. We have a second T4 template that's in charge of refreshing the DBML from the database, so we can ensure that tables have the 3 part prefix (db.schema.tbl) and so we don't have to delete and re-add to the designer. The XML just gets changed based on reading the db schema and updating the DBML. We also generate a repository/manager object for each POCO that have a few common query operations like GetByID(), and also handle commits and the audit logging. These managers get extended with all the custom queries you'd need to write against each table, and they own the DataContext. This design is sometimes known as the "Mommy-may-I?" approach, where the object Linqed to the table has to ask its manager to do everything for it.
I've found this to be a very versatile and slick way of doing L2S, and it's made our back-end development a breeze so that we can put our focus on the user experience. The only downside is that if we do associations across namespaces, you have to manually add those to the partial class yourself, because otherwise you'd have to add that foreign table to another DBML in order to draw the association. This is actually not such a bad thing as causes us to really think about the specificity of our namespaces and cut down extra ones. Using T4 this way is a great way to develop DRY (don't repeat yourself). The table definition is the only place you need to change the structure and it all propogates. Validation goes in one place, the POCO. Queries go in one place, the manager. If you want to do something similar, here's a good place to start.
即使设计器生成的类很混乱，但这对你来说有什么关系呢？
我敢说，绝对不需要打开其中一个设计文件。
如果您需要扩展模型中定义的任何实体，它们都是部分类，因此您可以创建自己的同名部分类并实现您的东西...
当我使用 L2S 时，我只使用设计器。
Even tho the Designer generated classes are messy, what does it matter to you?
There's, I dare say, absolutely no need to ever open one of the design files.
If you need to extend any of the entities defined in your model, they are all partial classes so you can just create your own partial class of the same name and implement your stuff...
When I do use L2S, I just use the designer.