如何使用LinqToSQL实现对ASP.NET MVC 2中的数据注释验证功能的自定义控制？

I'm using LinqToSQL, creating my entities with the designer in studio which nicely creates the designer class with all corresponding entity-classes. Normally when I wanted some custom stuff added to my entities, I would create a partial class and do the custom stuff there. Here's my problem; the new ASP.NET MVC 2 (preview) contains some nice Data Annotation Validation support, which allows you to do something like:

我正在使用LinqToSQL,在工作室中使用设计器创建我的实体,它可以很好地创建具有所有相应实体类的设计器类。通常当我想在我的实体中添加一些自定义的东西时,我会创建一个局部类并在那里做自定义的东西。这是我的问题;新的ASP.NET MVC 2(预览版)包含一些很好的数据注释验证支持,它允许您执行以下操作:

public class Customer 
{
    [Required(ErrorMessage = "Name is Required")]
    public string Name { get; set; }
}

Can anybody advise me how to handle this? I was hoping not to create an extra class and do some sort of mapping.. :( And it would be nice to keep the validation of my entities in my entities :)

任何人都可以告诉我如何处理这个问题?我希望不要创建一个额外的类,并做一些映射.. :(并在我的实体中保持我的实体验证将是很好的:)

I hope I'm making some sense here.. thanks in advance.

我希望我在这里有所作为..先谢谢你。

4 个解决方案

#1

I ran into this problem with MVC V1 and xVal. I ended up using "buddy classes" as detailed here Schotime (google cache as he's having website problems).

我遇到了MVC V1和xVal这个问题。我最后使用了“伙伴类”,详见Schotime(google缓存,因为他有网站问题)。

It works great for me, but I'm not familiar with MVC v2's method of doing this to know if its routines will "pick up" the metadata in your buddy classes.

它对我很有用,但我不熟悉MVC v2这样做的方法,以了解它的例程是否会“拾取”好友类中的元数据。

It's hard to argue with anybody who starts with "everybody has a different opinion", but I'd be loathe to modify the generated files for LINQ. I see the point about a scaffold, but when I'm in development I'm making so many changes to my db (and relationships) that I frequently drop a class and recreate by dragging the table back over. Sometimes I remove all classes and drag the entire db over. On the other hand, I guess this is evidence of poor planning on my part.

很难与任何以“每个人都有不同意见”开头的人争论,但我不愿修改LINQ生成的文件。我看到了关于脚手架的观点,但是当我在开发中时,我对我的数据库(和关系)进行了很多更改,我经常删除一个类并通过将表拖回来重新创建。有时我删除所有类并拖动整个数据库。另一方面,我猜这是我的计划不佳的证据。

#2

if I use LinqToSQL to generate a class, I always create a lightweight data container version of the class with a postfix of Data. I then use that class to transfer data to / from the client / server.

如果我使用LinqToSQL生成一个类,我总是创建一个带有后缀Data的类的轻量级数据容器版本。然后我使用该类向/从客户端/服务器传输数据。

I may not be describing this perfectly but I believe it is somewhat common practice.

我可能没有完美地描述这一点,但我认为这是一种常见的做法。

Say LinqToSql gives you a Car class with an int id, int doors, string color, int wheels based off the Cars table. I'd create

假设LinqToSql为您提供了一个Car类,它具有int id,int门,字符串颜色,基于Cars表的int轮。我创造了

public class CarData
{
    [Required(ErrorMessage = "ID is Required")]
    public int id { get; set; }

    [Required(ErrorMessage = "doors are Required")]
    public int doors { get; set; }

    [Required(ErrorMessage = "color is Required")]
    public string color { get; set; }

    [Required(ErrorMessage = "wheels are Required")]
    public int wheels { get; set; }
}

You can even use linq to select a new one of these via

您甚至可以使用linq从中选择一个新的

var myCar = 
     from c in MyDataContext.Cars 
     where c.id == 1 
     select new CarData()
     { 
          id = c.id, 
          doors = c.doors, 
          color = c.color, 
          wheels = c.wheels 
     };

You'll even retain linq to sql's delayed execution functionality with this as well. Anyway, you would add those attributes to this "Data" class (as shown), that way you have a specialized lightweight class that serializes easily and has all of the validation attributes you want.

您甚至可以将linq保留为sql的延迟执行功能。无论如何,您可以将这些属性添加到此“Data”类(如图所示),这样您就拥有了一个专门的轻量级类,它可以轻松地序列化并具有您想要的所有验证属性。

#3

Everyone has a different opinion but I am the kind of guy who goes ahead and edits generated files. If I can add a partial class then I will but for cases like this I would go ahead and edit the property in the generated file.

每个人都有不同的意见,但我是那种继续编辑生成文件的人。如果我可以添加一个部分类,那么我会,但对于这样的情况,我会继续编辑生成的文件中的属性。

A lot of generated files should be treated as a scaffold that is yours once the generator has spit it out. Once you start thinking about it that way some things can become a lot easier. By the way I wouldn't advocate this approach for a file that is going to be regenerated often as that would create many more headaches.

许多生成的文件应该被视为一个脚手架,一旦生成器吐出它就属于你的脚手架。一旦你开始这样思考,一些事情就会变得容易多了。顺便说一句,我不会提倡这种方法来处理一个经常重新生成的文件,因为这会产生更多的麻烦。

#4

Thank you for sharing your point of view on this. I thought about that, but I'm not sure if I want that.

感谢您分享您的观点。我想到了,但我不确定我是否想要那个。

The solution I came up myself was making all my generated entities abstract, and all my properties virtual, naming them "DBCustomer" for instance, and creating an inherited "Customer" class. Then overriding all properties, and call base.PropertyName in the getters and setters. What do you think about that?

我自己提出的解决方案是将所有生成的实体抽象化,并将所有属性设置为虚拟,例如将它们命名为“DBCustomer”,并创建一个继承的“Customer”类。然后重写所有属性,并在getter和setter中调用base.PropertyName。你觉得怎么样?

#1