Перший Рамковий кодекс сутності - Переваги та недоліки Fluent Api проти анотацій даних [закрито]


120

Створюючи базу даних за допомогою коду Entity Framework спочатку, з коду може бути витягнуто багато моделі бази даних. Для тонкої настройки моделі можна використовувати плавні API та / або атрибути.

Які переваги та недоліки Fluent Api порівняно з анотаціями даних? Іншими словами: Навіть якщо в певних ситуаціях можна використовувати обидва методи, у яких випадках один метод повинен переважати над іншим?


3
Просто ідея: зазвичай я створюю проект-проект за допомогою моїх POCO, а потім у проекті Repository створіть новий набір POCO, спеціально для EF, і помістіть туди свої анотації. Тоді я просто розміщую між двома в класах картографування. Таким чином, моя модель залишається недоторканою і полегшує додавання / зміну моєї стратегії даних, якщо це необхідно (наприклад, додайте XmlRepository і використовуйте ті самі класи Model).
adimauro

1
Зараз я віддаю перевагу Анотація, з EFCore та додатковими бібліотеками. (Вимагає менше коди, і все це в одному місці) github.com/isukces/EfCore.Shaman - надбудова і розширює атрибути github.com/borisdj/EFCore.FluentApiToAnnotation - корисно , коли БД вже існує, після виконання зворотного проектування і переходу на CodeFirst
borisdj

Відповіді:


141

Все, що можна налаштувати за допомогою DataAnnotations, також можливо за допомогою API Fluent. Зворотний неправда. Отже, з точки зору параметрів конфігурації та гнучкості API Fluent є "кращим".

Приклади конфігурації (точно не повний перелік), які можливі в Fluent API, але не з DataAnnotations (наскільки я бачу):

  • Вимкнення каскадних видалень:

    .WillCascadeOnDelete(false)

  • Укажіть ім'я стовпця з іноземним ключем у базі даних, коли ключ не відкритий у вашій об'єктній моделі:

    .Map(conf => conf.MapKey("MyForeignKeyID"))

  • Тонка деталізація відносин, особливо у всіх випадках, коли в об'єктній моделі виставляється лише одна сторона асоціації:

    .WithMany(...), WithOptional(...), WithRequiredDependent(...),WithRequiredPrincipal(...)

  • Специфікація відображення спадщини між об'єктною моделлю та таблицями баз даних (Таблиця-за-ієрархією, Таблиця-на-тип, Таблиця-за-конкретним-класом):

    .Map<TDerived>(Action<EntityMappingConfiguration<TDerived>> ...)

Редагувати: Microsoft розглядає API Fluent як "розширену функцію" (цитата звідси ):

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

Але, на мою думку, ви дуже швидко досягаєте обмежень DataAnnotations (за винятком, можливо, надзвичайно простих об'єктних моделей). Якщо ви більше не можете налаштувати свою модель за допомогою DataAnnotations, останньою можливістю є дотримуватися стандартних стандартів зіставлення карт (називаючи свої властивості відповідно до цих правил). В даний час ви не можете перезаписати конвенції (лише відключіть їх; MS оголосив про надання параметрів конфігурації для конвенцій у майбутніх випусках EF). Але якщо ви не хочете, щоб примусово домовлятися про умови відображення під час визначення вашої об'єктної моделі, єдиний варіант - API Fluent.

Навчання API Fluent - це майже обов'язково, DataAnnotations - це приємно мати прості програми.


2
Я новачок у цій галузі. Чи можна використовувати API Fluent для перевірки інтерфейсів користувача, як це може зробити DataAnnotation?
поцілуй мою пахву

27
@CounterTerrorist: Я не думаю, що так. Наприклад: Якщо ви помістите [Required]атрибут у властивість у програмі ASP.NET MVC, він буде використовуватися як EF, так і MVC для цілей перевірки, оскільки обидва можуть обробити цей атрибут. Але MVC не зрозуміє конфігурацію API Fluent. Отже, якщо ви видалите атрибут і HasRequiredзамість цього скористаєтеся Fluent API, для EF він буде таким же, але не для MVC. (На мою думку, атрибути повинні були бути названі по-різному; використання простору імен DataAnnotations з різних компонентів і для різних цілей дуже заплутано.)
Slauma

4
Зверніть увагу також, що [DefaultValue()]це неможливо в Fluent Either.
webnoob

4
MinValue - атрибут, який неможливо визначити за допомогою Fluent API (Framework Programme Entity Framework: Code First) (джерело: видалено NAA від Cog )
Сергій Баллеста

7
З архітектурної точки зору, мабуть, Fluent APIбуде збережено логіку вашої реалізації DbContextта зберегти POCOчистоту
Luke T O'Brien
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.