Чи вільні інтерфейси більш гнучкі, ніж атрибути, і чому?

У першому підручнику з коду EF 4.1 наведено наступний код:

public class Department
{
    public int DepartmentId { get; set; }
    [Required]
    public string Name { get; set; }
    public virtual ICollection<Collaborator> Collaborators { get; set; }
}

Потім пояснюється, що плавний інтерфейс є більш гнучким:

Анотації даних, безумовно, прості у використанні, але бажано використовувати програмний підхід, який забезпечує набагато більшу гнучкість.

Далі наведено приклад використання вільного інтерфейсу:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Department>().Property(dp => dp.Name).IsRequired();
    modelBuilder.Entity<Manager>().HasKey(ma => ma.ManagerCode);
    modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .IsConcurrencyToken(true)
        .IsVariableLength()
        .HasMaxLength(20);
}

Я не можу зрозуміти, чому вільний інтерфейс нібито кращий. Це насправді? З моєї точки зору, схоже, що анотації до даних є більш чіткими і мають більше чистого семантичного відчуття.

Моє запитання: чому міг би вільний інтерфейс бути кращим варіантом, ніж використання атрибутів, особливо в цьому випадку?

(Примітка. Я зовсім новачок у всій концепції вільних інтерфейсів, тому, будь ласка, не очікуйте, що попередніх знань щодо цього немає.)

Довідка: http://codefirst.codeplex.com/

Анотації даних є статичними, наприклад, цей спосіб оголошення не може змінюватися під час виконання:

  [MinLength(5)]
  [MaxLength(20,ErrorMessage="Le nom ne peut pas avoir plus de 20 caractères")]
  public new string Name { get; set; }

Вільний інтерфейс може бути динамічним:

   if (longNamesEnabled)
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(100);
   }
   else
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(20);
   }

не кажучи вже про код, можна використовувати повторно між властивостями.

Я не думаю, що це твердження слід широко застосовувати; він дуже специфічний для Кодексу Першого. У Code First, анотації даних містять лише підмножину функціональних можливостей, доступних у вільному API. Іншими словами, є певні модельні конфігурації, які можна виконати лише за допомогою вільного API.

Наприклад, ось деякі речі, які неможливо вказати за допомогою приміток:

• Точність властивості DateTime
• Точність та масштабність числових властивостей
• Властивість String або Binary як фіксованої довжини
• Властивість String як не-унікод
• Поведінка на видалення відносин
• Розширені стратегії картографування

Особисто я схильний використовувати анотації даних, пов’язаних з валідацією, коли це можливо, оскільки інші технології, такі як MVC, також можуть скористатися ними. Для всього іншого я віддаю перевагу вільному API.

Відповідь на ваше запитання надається за посиланням.

Потім ви визначаєте свої обмеження, застосовні до вашого домену в рамках цього методу програмно.

В основному, більш-менш переважно використовувати атрибути проти програмного підходу, де програмний підхід має більше контролю над сутністю. Однак існує спеціальний спосіб додавання атрибутів для прикраси вашої моделі, який ви також можете виглядати.

Використовуючи такий підхід, ви навіть можете описати відносини між таблицями та стовпцями. Підсумок, якщо ви бажаєте мати більш тонкий контроль над своїм доменом, ви можете використовувати цей новий підхід, який постачається з EF4.1.

Однак для загальних сценаріїв перевірки застосування атрибутів має працювати добре, оскільки це надійно охоплює більшість випадків; і крім того, це може заощадити ваш час.

Думаю, що вони рекомендують вільний API для перших реалізацій коду, оскільки ви чітко описуєте, як створюються відносини в базі даних. Якщо ви використовуєте примітки про дані, база даних, створена Entity Framework, може бути не такою, яку ви очікуєте. Ваш початковий приклад дуже простий, тому, як і ви, я б просто використовував метод анотації даних.