Атрибуты и аннотации: метаданные против чистоты кода

Атрибуты (Attributes) в языке C# - это удобный способ добавления метаданных к классу, свойству или методу. Этот инструмент иногда может быть очень полезным, но всегда ли его применение оправдано? Например, допустим у нас имеется класс Person:

• public class Person {
• public string FirstName {get; set;}
• public string LastName {get; set;}

}

С помощью атрибута Serializable можно указать, что экземпляры этого класса могут сериализоваться, не используя интерфейс ISerializable:

• [Serializable]
• public class Person {
• public string FirstName {get; set;}
• public string LastName {get; set;}
• }

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

Допустим, наш объект Person храниться в базе данных и мы решили использовать ORM фреймворк для его получения/сохранения. Большинство ORM фреймворков допускают два типа настройки меппинга - через атрибуты или через xml-конфигурацию. Допустим, мы выбрали вариант с атрибутами. Наш класс превратится во что-то вроде этого:

• [Serializable]
• [Table(Name="person")]
• public class Person {
• [Column(Name="first_name")]
• [AllowNull(false)]
• [PrimaryKey]
• public string FirstName {get; set;}
• [Column(Name="last_name")]
• [AllowNull]
• public string LastName {get; set;}
• }

Далее, допустим нам нужно использовать фреймворк для валидации, который также предоставляет возможность конфигурации через атрибуты. Наш класс снова меняется:

• [Serializable]
• [Table(Name="person")]
• public class Person {
• [Column(Name="first_name")]
• [AllowNull(false)]
• [PrimaryKey]
• [Required]
• [MaxLength(50)]
• [MinLength(10)]
• public string FirstName {get; set;}
• [Column(Name="last_name")]
• [AllowNull]
• [Required]
• [MaxLength(20)]
• [MinLength(5)]
• public string LastName {get; set;}
• }

Теперь давайте посмотрим на наш класс. Во-первых он стал в два раза больше по количеству строк. Если учесть, что добавленные строки - это метаданные, а не код, то очевидно, что читаемость кода ухудшилось. Но это не самое плохое.

А плохо то, что наш класс теперь зависит от классов фреймворков ORM и валидации. А так как Person - класс предмеьной области, то он должен быть отделен от слоя доступа к данным и рендеринга вида. Причем, это разделение пожет быть как условным, так и физическим, когда предметная область выделена в отдельную сбоку/jar.

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

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