Блок проверки корпоративной библиотеки - следует ли проводить проверку класса или интерфейса?

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

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

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

validation class interface enterprise-library
person Robert MacLean    schedule 19.01.2009    source источник

Ответы (4)


arrow_upward
1
arrow_downward

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

person Perpetualcoder    schedule 19.01.2009

arrow_upward
1
arrow_downward

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

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

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

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

person Paul    schedule 09.11.2009

arrow_upward
0
arrow_downward

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

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; }
}
}
person Robert MacLean    schedule 20.01.2009

arrow_upward
0
arrow_downward

Какую версию 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);

Это помогло мне.

person Eric    schedule 05.04.2012