Только код EF POCO VS EF POCO с моделью данных объекта - PullRequest
Новая
       43

Только код EF POCO VS EF POCO с моделью данных объекта

19 голосов
/ 23 февраля 2011

Возможность полностью отделить доменные объекты от любого вида кода персистентности делает системы намного более расширяемыми и обслуживаемыми.Тестирование становится намного проще, когда бизнес-логику можно тестировать отдельно от кода хранилища.Использование POCO с Entity Framework (EF) определенно является шагом в правильном направлении:)

Существует 2 типа использования poco с EF 1. Использование конструктора объектов 2. Использование только кода

какой из них лучше всего подходит в первую очередь для EF Poco-кода или EF Poco с использованием конструктора модели данных объекта?

спасибо

1 Ответ

18 голосов
/ 23 февраля 2011

Это просто вопрос выбора.

EFv4 с конструктором

Плюсы:

  • У вас есть поддержка конструктора и шаблон T4, который будет генерировать для вас объекты = RAD.
  • У вас очень большой набор функций, включая поддержку представлений, сопоставления хранимых процедур и некоторых объектов, определенных пользовательской моделью, таких как QueryView или функция, определенная моделью.
  • Поддержка других типов EF, когда это необходимо (объекты самообследования, объектобъекты).

Минусы:

  • Конструктор не очень хороший инструмент для больших моделей (более 50 таблиц)
  • Не все функции поддерживаются в конструкторе- вы должны получить доступ к EDMX как XML
  • Структура EDMX XML, вероятно, является наиболее сложным и трудным для понимания описанием среди всех доступных инструментов .NET ORM
  • Работа в общей среде с дизайнером - это просто боль -лучше использовать эксклюзивные замки на EDMX
  • Редактировать: Я забыл свой очень популярный недостаток.Дизайнер сохраняет все данные отображения в EDMX вместе со своими собственными данными о позиционировании объектов на диаграмме.Даже такое глупое действие, как масштабирование диаграммы, проверит файл EDMX из системы управления исходным кодом.

Сначала код EF

Плюсы:

  • Возможность определять все в коде
  • Отображение на основе атрибутов и Fluent API
  • Некоторые очень приятные функции API - соглашения, Local и т. Д.
  • Я думаю, что этот API меньшесложный и простой в использовании

Минусы:

  • Это еще не окончательный выпуск.Текущий выпуск - только предварительный просмотр технологии сообщества. 5.
  • Из-за этого API может измениться в окончательном выпуске.
  • Вы должны написать весь код самостоятельно.
  • Набор функций ограничен по сравнениюна "большой" EF.
  • Нет документации, в настоящее время вам придется искать информацию в блогах.

В настоящее время я использую первый подход.После финального релиза я, возможно, буду более доволен первым.

...