Атрибут с действие/условие

Това не е добра идея

Ще бъде неоправдано трудно да направите нещо подобно на това, което описвате, и резултатът няма да бъде поддържан дори и да сте успели да го направите.

Трудността произтича от ограниченията върху параметрите на атрибутите:

Параметрите на атрибутите са ограничени до постоянни стойности от следните типове:

• Скаларни типове (bool, byte, char, short, int, long, float и double)
• string
• System.Type
• изброявания
• object (което трябва да е постоянна стойност от един от горните типове)
• Едномерни масиви от който и да е от горните типове

Очевидно е, че единственият начин да вмъкнете предикат в някой от горните типове е като напишете низ а-ла SQL, напр.

[Hide("foo = \"42\" && !bar")]
public object MyProperty { get; set; }

След това ще трябва да анализирате този низ по време на изпълнение, да го преобразувате в машинно използваема форма и да решите какъв ще бъде резултатът. И дори тогава би било много лесно да напишете невалиден предикат, тъй като низът е напълно непрозрачен за компилатора.

Но има алтернативи

Вашето опитано решение наистина се опитва да плува срещу течението - атрибутите не са предназначени да капсулират поведението по време на изпълнение. Вместо да правите това, защо просто не накарате вашия сериализуем клас да имплементира подходящ интерфейс? Например, можете да започнете със стандарта за блато

public interface IConditionalPropertySource
{
    bool IsPropertyApplicable(string propertyName);
}

class Test : IConditionalPropertySource
{
    public string SomeSetting { get; set; }

    public bool IsPropertyApplicable(string propertyName)
    {
        switch (propertyName)
        {
            case "SomeSetting":return DateTime.Now.DayOfWeek == DayOfWeek.Friday;
            default: return false;
        }
    }
}

Това ще свърши работа, но има някои недостатъци:

1. Имената на свойствата не се проверяват от компилатора; както повикващият, така и изпълнението на IsPropertyApplicable могат да направят грешки (напр. просто грешно изписване), които няма да бъдат маркирани.
2. Не е веднага ясно кои свойства са условни и кои не са само чрез гледане на техните декларации.
3. Точната връзка между свойства и условия е донякъде скрита.

Със сигурност и по време на компилиране

Ако горното не е задоволително, можете да го подобрите, като елиминирате първите два проблема и подобрите третия срещу малка цена на изпълнение. Идеята се основава на добре известен трик за осигуряване безопасност по време на компилиране при препратка към имена на свойства: вместо да ги указвате като низ, укажете ги като изрази за достъп на член.

public interface IConditionalPropertySource<T>
{
    bool IsPropertyApplicable(Expression<Func<T, object>> expr);
}

Можете да извикате горното като IsPropertyApplicable(o => o.SomeSetting) и да получите "SomeSetting" като низ по време на изпълнение с ((MemberExpression)expr.Body).Member.Name. Въпреки това, ние наистина не искаме да работим с гол низ по всяко време, защото това би означавало, че проблем №1 по-горе все още съществува.

Така че вместо това, можем да създадем речник, който съпоставя изразите за достъп на член към булеви функции и да предоставим инструмент за сравнение на равенство, който замества семантиката за равенство по подразбиране за изрази (референтно равенство) с равенство на име на член:

class Test : IConditionalPropertySource<Test>
{
    // Your properties here:
    public string SomeSetting { get; set; }

    // This is the equality comparer used for the dictionary below
    private class MemberNameComparer :
        IEqualityComparer<Expression<Func<Test, object>>>
    {
        public bool Equals(
            Expression<Func<Test, object>> lhs, 
            Expression<Func<Test, object>> rhs)
        {
            return GetMemberName(lhs).Equals(GetMemberName(rhs));
        }

        public int GetHashCode(Expression<Func<Test, object>> expr)
        {
            return GetMemberName(expr).GetHashCode();
        }

        private string GetMemberName(Expression<Func<Test, object>> expr)
        {
            return ((MemberExpression)expr.Body).Member.Name;
        }
    }

    // A dictionary that maps member access expressions to boolean functions
    private readonly IDictionary<Expression<Func<Test, object>>, Func<bool>> 
        conditions = new Dictionary<Expression<Func<Test, object>>, Func<bool>>
        (new MemberNameComparer())
        {
            // The "SomeSetting" property is only visible on Wednesdays
            { 
                self => self.SomeSetting, 
                () => DateTime.Now.DayOfWeek == DayOfWeek.Wednesday
            }
        };


    // This implementation is now trivial
    public bool IsPropertyApplicable(Expression<Func<Test, object>> expr)
    {
        return conditions[expr]();
    }
}

Това елиминира проблем #1 (вече не можете да пишете грешно имената на свойствата, компилаторът ще го улови) и подобрява #3 (свойствата и условията са малко по-видими). Той все още оставя проблем #2 неразрешен: не можете да разберете дали SomeProperty е условно видим само като погледнете неговата декларация.

Можете обаче да разширите кода, за да наложите това по време на изпълнение:

• Украсете условно видимите свойства с персонализиран атрибут
• Вътре в конструктора избройте всички свойства на класа, декорирани с този атрибут, и всички имена на свойства, които могат да бъдат получени от ключовете на речника
• Третирайте и двете изброени колекции като набори
• Ако наборите не са равни, има несъответствие между свойствата, които са декорирани, и тези, които имат дефинирана логика на условна видимост; издаване на изключение

Както @Jon вече посочи, използването на атрибути не е правилният начин.

В моя случай най-удовлетворяващото решение досега е да се декларира друго свойство със суфикс Hide, който съдържа код за проверка на условието и се използва чрез отражение в ConfigWrapper за проверка кога да добавите тази настройка или не:

public SomeType SomeSetting1 { get; set; }

public SomeType SomeSetting2 { get; set; }
protected SomeType SomeSetting2Hide { get { return SomeSetting3 = 4 && SomeSettings4 < 100; } }

Тази настройка трябва да бъде декларирана като protected (първоначално направих глупава грешка), за да се скрие самата тя от публичните настройки.

И след това в обвивката на конфигурацията:

    public ConfigWrapper(object obj)
    {
        _original = obj;
        // copy all properites
        foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(obj))
        {
            // filter hideable attributes
            bool add = true;
            foreach (Attribute attribute in property.Attributes)
                if (attribute is Common.IHide && (attribute as Common.IHide).Hide)
                {
                    add = false;
                    break;
                }

            ////////////////////////

            // filter configurable via hide property properties
            var hide = obj.GetType().GetProperty(property.Name + "Hide", BindingFlags.Instance | BindingFlags.NonPublic);
            if (hide != null && (bool)hide.GetValue(obj, null))
                add = false;

            ///////////////////////

            // add
            if (add)
                _collection.Add(new ConfigDescriptor(property));
        }
    }

Можете да разгледате тази рамка:

http://www.codeproject.com/Articles/415070/Dynamic-Type-Description-Framework-for-PropertyGri

Това има много динамични функции.