Применение атрибутов в C#

Это косательно форм. А допустим, контроль доступа, маршрутизация для запросов в ASP.NET через атрибуты — это было бы интереснее. К слову, я даже не знаю можно ли последнее через атрибуты задать.

Суть в том, что в оригинале этот психологический термин и был выбран в качестве названия неймспейса (самокопание же). Но MSDN, видимо, переводили те же люди, что обозвали overmind надмозгом.

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

Так, PEVerify'ить надо сначала. И тестировать везде, где генератор может работать.
И с чего, вдруг, накладное-то, кстати? Накладное — через CodeDom, да и то несущественно, если все делается при запуске приложения или по первому обращению. Reflection.Emit же вообще охренительно быстр.

А я про что сказал?
Такой же инструмент. Имеет достоинства и недостатки. Один из недостатков — весьма вероятное снижение скорости выполнения приложения в отдельных случаях, к которым приведенный автором пример не относится. Но это не единственный пример применения, и во многих случаях следует не использовать рефлексию «в лоб», а воспользоваться слегка другим подходом.

ух-ты, парсер-молодец. Вечно забываю, что в теге code дублируются переносы строк. Прошу прощения за портянку.

Это слово «индексатор»?
На хабре, для оформления кода можно использовать вмето тега code — тег source, с атрибутом lang=«c#» или lang=«cs» (c# иногда глючит).

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

Коли ночь на дворе, а сна нет, расскажу подробнее, как это делаю я. Материал много где дублируется в сети, и, скорее всего, не будет откровением, но кому-то может пригодиться.

Во ViewModel, которую мы хотим валидировать, реализуем интерфейс IDataErrorInfo. В этом интерфейсе два метода: один позволяет указать на ошибку в конкретной проперти, другой отвечает за валидацию модели в целом. Начну с валидации одного свойства.

public virtual string this[string columnName]
{
   get { return AttributesValidation.Validate(this, columnName); }
}

На вход этого… забыл слово… подаётся название свойства, которое надо валидировтаь. На выходе — либо строка с описанием ошибки, либо string.Empty.
Для валидации аттрибутами у меня есть небольшой класс-хелпер:

internal static class AttributesValidation
{
   public static string Validate(IDataErrorInfo source, string columnName)
   {
   var type = source.GetType();
   var property = type.GetProperty(columnName);
   var validators = (ValidationAttribute[]) property.GetCustomAttributes(typeof (ValidationAttribute), true);
   if (validators.Any())
      {
         var value = property.GetValue(source, null);
         var errors = validators.Where(v => !v.IsValid(value)).Select(v => v.ErrorMessage ?? "").ToArray();
         return string.Join(Environment.NewLine, errors);
      }
   return string.Empty;
   }
}

Все валидаторы, которые есть, они наследуются от System.ComponentModel.DataAnnotations.ValidationAttribute.

Ну а теперь это всё необходимо обработать в WPF:

[TextBox Text="{Binding Path=Name, Mode=TwoWay, NotifyOnValidationError=True, UpdateSourceTrigger=PropertyChanged, ValidatesOnDataErrors=True}" /]

Для несложных проверок мне нравится ставить UpdateSourceTrigger=PropertyChanged. В этом случае (длят екстбокса) валидация происходит после каждого нажатия клавиши, а не после потери фокуса. Это нагляднее, но больше обработок и вычислений.
Этот снипет даёт красную рамку вокруг невалидных полей и вызов обработчика ошибок в валидаторе формы. То есть, можно сделать так:

class MyForm{
int _errCount;

public MyForm()
{
   Validation.AddErrorHandler(this, OnChildControlError); // и на каждое появление ошибки валидации или пропадание ошибки валидации будет вызываться OnChildControlError.
}

protected void OnChildControlError(object sender, ValidationErrorEventArgs e)
{
   switch (e.Action)
   {
   case ValidationErrorEventAction.Added:
      _errCount += 1;
      break;
   case ValidationErrorEventAction.Removed:
      _errCount -= 1;
      break;
   default:
      throw new ArgumentOutOfRangeException();
   }
   // теперь в переменной _errCount у нас записано количество ошибочных полей, и мы можем делать какое-то действие, например задизаблить кнопку OK. Я предпочитаю объявить DependencyProperty Valid, и с ним работать в xaml. 
   Valid = _errCount == 0;
}

Таким образом, если всё это сплести в одну кучу, то мы получаем:
1. ViewModel умеет сообщать о своих ошибках через [propertyName]
2. Специальный валидатор умеет валидировать модели через атрибуты
3. xaml умеет помечать красным невалидные филды
4. Viewшка (например, форма или UserControl) умеет считать невалидные филды внутри себя и имеет DependcyProperty Valid, к которому можно биндить Enabled-свойство кнопок.

Вывод сообщений об ошибке в xaml я не буду расписывать, так как это есть в msdn и stackoverflow, а комментарий итак получается очень большим.