Все, что вы можете настроить с помощью DataAnnotations, также возможно с помощью Fluent API. Обратное неверно. Итак, с точки зрения возможностей конфигурации и гибкости Fluent API «лучше».
Примеры конфигурации (конечно, не полный список), которые возможны в Fluent API, но не с DataAnnotations (насколько я могу судить):
Отключить каскадное удаление:
.WillCascadeOnDelete(false)
Укажите имя столбца внешнего ключа в базе данных, если ключ не отображается в вашей объектной модели:
.Map(conf => conf.MapKey("MyForeignKeyID"))
Тонкая настройка взаимосвязей, особенно во всех случаях, когда в объектной модели отображается только одна сторона ассоциации:
.WithMany(...)
, WithOptional(...)
, WithRequiredDependent(...)
,WithRequiredPrincipal(...)
Спецификация сопоставления наследования между объектной моделью и таблицами базы данных (Table-Per-Hierarchy, Table-Per-Type, Table-Per-Concrete-Class):
.Map<TDerived>(Action<EntityMappingConfiguration<TDerived>> ...)
Изменить: Microsoft считает Fluent API «расширенной функцией» (цитата отсюда ):
Свободный API считается более продвинутой функцией, и мы рекомендуем использовать аннотации к данным, если только ваши требования не требуют использования беглого API.
Но, на мой взгляд, вы очень быстро достигнете ограничений DataAnnotations (за исключением, возможно, чрезвычайно простых объектных моделей). Если вы больше не можете точно настроить свою модель с помощью DataAnnotations, ваше последнее средство - следовать соглашениям о сопоставлении по умолчанию (путем именования ваших свойств в соответствии с этими правилами). В настоящее время вы не можете перезаписывать соглашения (только отключите их; MS объявила, что предоставит параметры конфигурации для соглашений в будущих выпусках EF). Но если при определении объектной модели вы не хотите, чтобы вас принуждали к соглашению о сопоставлении, единственный вариант - это Fluent API.
Изучение Fluent API почти обязательно, имхо, DataAnnotations - полезный инструмент для простых приложений.