проверка ввода контроллера в MVC API

Question

Я построил 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, но, похоже, нужно создавать правила наоснова класса не класс / действие.

спасибо.

Answer 1

Что такое 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 может фокусироваться на простом представлении объекта пользователя, в отличие от иногда , представляющего еще не созданного пользователя, или иногда , представляющего только идентификатор пользовательского объекта, и т.д.

Одним из основных преимуществ является то, что вы можете указать правила проверки прямо в классе. При таком подходе объект User может всегда требовать, чтобы Username и и ID были действительными. Принимая во внимание, что у объекта CreateUserAction нет даже ID (поскольку он не нужен), а у объекта DeleteUserAction нет Username (так как он не нужен).

При необходимости вы можете добавить дополнительные поля. Например, объект CreateUserAction, скорее всего, будет иметь другие поля для описания создаваемого пользователя. (Он может даже иметь поля, которые вообще не идут на объекте User, но будут преобразованы в какой-то другой объект в домене.) Однако, DeleteUserAction может никогда не понадобиться ничего, кроме ID ( и, как предлагает SLaks, вероятно, можно заменить просто int для этого метода действия, но это на ваше усмотрение).

Более четкие роли и обязанности для классов, меньше частично инициализированных полуобъектов.