Существуют ли конкретные случаи использования пользовательских атрибутов в классе вместо свойств? Я знаю, что свойства предпочтительны из-за их открытости и производительности, но атрибутов... Когда я должен определенно использовать их?
UPDATE:
Здесь - сообщение Эрика Липперта об этом решении.
У Эрика Липперта есть отличный пост в блоге, решающий именно это решение.
Его резюме:
Вкратце: используйте атрибуты для описания ваших механизмов, используйте свойства для моделирования домена.
Я бы также добавил, что соображение о том, что значение атрибута является фактически статическим - другими словами, оно является частью описания типа, а не любым экземпляром типа.
Один сложный бит может появиться, когда каждый экземпляр некоторого базового типа должен иметь свойство (например, описание), но разные конкретные производные типы хотят указывать описания для каждого типа, а не для каждого экземпляра. Вы часто получаете виртуальные свойства, которые всегда возвращают константы - это не очень удовлетворительно. Я подозреваю, что ссылки на класс Delphi могут помочь здесь... не уверен.
EDIT: дать пример механизма, если вы украсите тип, чтобы сказать, в какой таблице он находится в базе данных, который описывает механизм передачи данных, а не говорит что-либо о модели передаваемых данных.
Существует два варианта использования:
1) Использование настраиваемого атрибута, который кто-то еще определил, например атрибут System.LoaderOptimization, который может использоваться в методе Main. Эти атрибуты используются, чтобы направить код платформы, такой как CLR, WPF, WCF или отладчик, чтобы запустить код определенным образом и может быть очень полезным время от времени. Чтение книг на разных платформах - это хороший способ узнать, когда и как использовать эти атрибуты.
2) Создание собственного пользовательского атрибута и его использование для украшения класса (или метода, свойства и т.д.). Они не имеют эффекта, если у вас также нет кода, который использует Reflection, чтобы заметить эти атрибуты и каким-то образом изменить поведение. Этого следует избегать по возможности из-за очень низкой производительности, на порядок превышающей, скажем, доступ к статическому члену класса.