MVC API中的控制器输入验证 [英] controller input validation in mvc api

查看:69
本文介绍了MVC API中的控制器输入验证的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经构建了一个api,并且需要验证作为参数传递给控制器​​操作的输入对象. 有时,相同的输入类别对于不同的操作将具有不同的强制属性.

如此

public class test
{
public ActionResult Create(User user)
{
  //here user_name must be present but no user_id
}
public ActionResult Delete(User user)
{
  //here only user_id must be present.
}
}

我看过fluentValidation.net,但似乎必须基于每个类而不是类/动作来创建规则.

谢谢.

解决方案

什么是User?

我的意思不是在哪里定义了类,而是在领域中从物理上讲是什么意思?听起来您好像想让它表示多件事.

不要尝试将这些操作适合域模型,而应为它们创建操作模型.像这样:

class CreateUserAction
{
  public string Username {get; set;}
}

class DeleteUserAction
{
  public int ID {get; set;}
}

然后在您的操作方法中使用这些:

public ActionResult Create(CreateUserAction user)
{
}

public ActionResult Delete(DeleteUserAction user)
{
}

这将根据单一责任原则将不同目的划分为不同的类别.现在,User类可以专注于简单地表示用户对象,而有时表示尚未创建的用户,或者有时仅表示用户的ID.对象等.

这里的一个主要好处是您可以直接在类中指定验证规则.使用这种方法,User对象可能总是 要求Username ID才有效. 对象甚至没有ID(因为它不需要一个),而DeleteUserAction对象没有Username(因为它不需要一个).

您可以根据需要进一步添加其他字段.例如,CreateUserAction对象将可能具有其他字段来描述正在创建的用户. (它甚至可能具有完全不在User对象上的字段,但是会转换为域中的其他对象.)但是,DeleteUserAction可能只需要一个ID(并且,如SLaks所建议,可以用该动作方法的int代替,但这取决于您).

类的角色和职责更清晰,部分初始化的半对象更少.

i have built an api and need to validate input objects passed as parameters to controller actions. Sometimes the same input class will have differing compulsory properties for different actions.

so

public class test
{
public ActionResult Create(User user)
{
  //here user_name must be present but no user_id
}
public ActionResult Delete(User user)
{
  //here only user_id must be present.
}
}

I have had a look at fluentValidation.net but it seems one has to create rules on a per class basis not class/action.

thanks.

解决方案

What is a User?

I don't mean in the sense of where is the class defined, but in the sense of what does it physically mean in the domain? It sounds like you're trying to get it to mean multiple things.

Instead of trying to fit these actions into a model for the domain, create action models for them. Something like this:

class CreateUserAction
{
  public string Username {get; set;}
}

class DeleteUserAction
{
  public int ID {get; set;}
}

Then use these in your action methods:

public ActionResult Create(CreateUserAction user)
{
}

public ActionResult Delete(DeleteUserAction user)
{
}

This will break out the different purposes into different classes, in accordance with the single responsibility principle. Now the User class can focus on simply representing a user object, as opposed to sometimes representing a not-yet-created user or sometimes representing only the ID of a user object, etc.

One major benefit here is that you can specify the validation rules directly in the class. With this approach, a User object can always require a Username and an ID to be valid. Whereas a CreateUserAction object doesn't even have an ID (since it doesn't need one) and a DeleteUserAction object doesn't have a Username (since it doesn't need one).

You can further add additional fields as needed. For example, the CreateUserAction object will likely have other fields to describe the user being created. (It may even have fields that don't go on a User object at all, but would be translated into some other object in the domain.) However, the DeleteUserAction may never need anything more than an ID (and, as suggested by SLaks, can probably be replaced with just an int for that action method, but that's up to you).

Clearer roles and responsibilities for classes, fewer partially-initialized half-objects.

这篇关于MVC API中的控制器输入验证的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆