Блок валидации корпоративной библиотеки. Следует ли проводить валидацию для класса или интерфейса? - PullRequest
1 голос
/ 19 января 2009

Я не уверен, где лучше всего разместить валидацию (используя блок валидации Enterprise Library)? Это должно быть в классе или на интерфейсе?

Вещи, которые могут повлиять на это

  • Правила проверки не будут изменены в классах, которые наследуются от интерфейса.
  • Правила проверки не будут изменены в классах, которые наследуются от класса.
  • В большинстве случаев наследование будет происходить от класса - я подозреваю, что некоторые дополнительные случаи наследуются от интерфейса (но я бы попытался этого избежать).
  • Основное использование интерфейса предназначено для DI, что будет сделано с блоком Unity.

Ответы [ 4 ]

1 голос
/ 09 ноября 2009

Будьте очень осторожны, ваш тест слишком прост.

Это не будет работать так, как вы ожидаете для SelfValidation Validators или Class Validators, только для простых валидаторов свойств, которые есть у вас.

Кроме того, если вы используете PropertyProxyValidator на странице ASP.NET, я не верю, что он тоже будет работать, потому что он выглядит только как валидаторы полей, а не как унаследованные / реализованные валидаторы ...

Да, большие дыры в VAB, если вы спросите меня ...

1 голос
/ 19 января 2009

То, как вы пытаетесь использовать блок проверки с DI, я не думаю, что это проблема, если вы установите атрибуты на уровне интерфейса. Кроме того, я не думаю, что это должно создавать проблемы в цепочке наследования. Тем не менее, я в основном видел этот блок, используемый на уровне класса, с намерением сохранить интерфейсы не слишком точными. ИМО, я не вижу в этом большой угрозы.

0 голосов
/ 05 апреля 2012

Какую версию Enterprise Library вы используете для своего примера кода? Я попробовал это с помощью Enterprise Library 5.0, но это не сработало.

Я отследил его до следующего раздела кода с исходным кодом EL5.0:

[namespace Microsoft.Practices.EnterpriseLibrary.Validation]
[public static class Validation]

public static ValidationResults Validate<T>(T target, ValidationSpecificationSource source)
{
    Type targetType = target != null ? target.GetType() : typeof(T);
    Validator validator = ValidationFactory.CreateValidator(targetType, source);
    return validator.Validate(target);
}

Если целевой объект определен, то target.GetType () вернет самое конкретное определение класса, а НЕ определение интерфейса.

Мой обходной путь - заменить вашу линию:

ValidationResults r = Validation.Validate<ISpike>(spike);

С:

ValidationResults r ValidationFactory.CreateValidator<ISpike>().Validate(spike);

Это заставило меня работать.

0 голосов
/ 20 января 2009

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

using System;
using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

namespace ConsoleApplication1
{
    class Program
    {
    static void Main(string[] args)
    {
        ISpike spike = new Spike();
        spike.Name = "A really long name that will fail.";
        ValidationResults r = Validation.Validate<ISpike>(spike);
        if (!r.IsValid)
        {
            throw new InvalidOperationException("Validation error found.");
        }

    }
}

public class Spike : ConsoleApplication1.ISpike
{
    public string Name { get; set; }
}

interface ISpike
{
    [StringLengthValidator(2, 5)]
    string Name { get; set; }
}
}
...