Проверка уровня сервиса MVC3. Возврат исключения, пользовательский объект, словарь состояния модели?

Question

Просто любопытно, что вы думаете или испытываете при проверке уровня обслуживания.

Мне нужно обработать достаточно стандартную проверку, например, «объект со свойством name еще не существует», но я не был уверен, как вернуть эти ошибки проверки обратно в контроллер.

Моей первоначальной мыслью было внедрение стандарта List<ValidationError>, но я видел, как он делал все и каждый, поэтому было любопытно плюсы / минусы каждого.

Спасибо за любой вклад.

Answer 1

Если вы используете записи System.ComponentModel.DataAnnotations, вы можете (как вы, кажется, знаете) украсить свои свойства необходимыми и многими другими тегами

public class Person
{
    [Required(ErrorMessage="object with name property doesn't already exist")]
    public string Name { get; set; }
}

, хотя я лично использую ViewModels, а не выставляю доменные mdoelsк вашему мнению, действие вашего контроллера теперь может делать что-то вроде:

[HttpPost]
public ActionResult SavePerson(Person model)
{
    if (ModelState.IsValid)
    {
        // your model validates - do things

        return RedirectToAction("success view here");
    }
    return View(model);
}

Это один из стандартных шаблонов обработчиков 'post' в MVC.На мой взгляд, это самый простой путь к проверке вашей объектной модели.

Отсюда есть несколько других вариантов - ваш доменный объект может реализовать IValidatedableObject, и вы можете yield return ошибки (см. ).http://buildstarted.com/2010/09/20/mvc-3s-ivalidatableobject/ в качестве примера).

Я бы порекомендовал не смешивать два из них, хотя, если вы используете dataannotations и даже имеете единственное недопустимое свойство, метод IsValid для IValidatableObject не будет вызываться.

Оттуда можно многое сделать с помощью пользовательских атрибутов проверки (расширенная версия IsValid, кажется, дает вам большую гибкость http://msdn.microsoft.com/en-us/library/gg480674%28v=vs.98%29.aspx)

Надеюсь, что некоторые из вышеперечисленных помогут - как только вы освоите основыс этим можно многое сделать, и такие вещи, как проверка клиентом пользовательских атрибутов и т. д., очень забавны.

Приветствия, Терри

[изменить, чтобы добавить:

После повторного-Читая ваше сообщение, может быть, вы хотите проверить только на уровне службы? Если так, я использовал следующий подход:

public void Setname(string newName)
{
    Validator.ValidateProperty(newName, new ValidationContext(this, null, null) { MemberName = "Name" });

    Name = newName;
}

obviДля этого вашему свойству Name потребуется { get; private set; }, хотя вы всегда можете добавить Validator.ValidateProperty в расширенный установщик для открытого свойства.

]

Answer 2

В новом проекте, над которым я работаю (впервые mvc), я использую контракты кода MS (которые генерируют исключения) и выполняю всю проверку для моих объектов домена.Для вещей, которые не могут быть проверены там (например, проверки, которые требуют доступа к базе данных), я проверяю в своих службах и выкидываю исключения.Кроме того, как и на приведенном выше плакате, у меня есть отдельные модели представления для всего, что имеет валидаторы аннотаций данных.Возникают исключения, и я ловлю их в контроллере и добавляю в ModelState.Существует много совпадений с ними и проверкой модели представления, но это не требует особых усилий и позволяет мне изменять проверку для каждого представления, но при этом все еще требуются «основные» проверки.

Book pro asp mvcУ 2 есть еще один приятный способ - написать класс, который наследует Exception и содержит коллекцию ошибок.Затем вы делаете свои проверки, добавляете в коллекцию, затем генерируете исключение, затем он ловит его в контроллере и копирует в ModelState.Этот метод позволит вам отлавливать ВСЕ ошибки в одном исключении, а не только на уровне службы.