проверка входного сигнала контроллера в 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и a ID. В то время как объект CreateUserAction даже не имеет ID (так как он не нужен), а объект DeleteUserAction не имеет Username (так как он не нужен).

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

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