Подтвердить что ты не робот

Код EF POCO только VS EF POCO с моделью данных сущности

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

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

какой из них лучше всего подходит для кода EF poco или EF Poco, используя конструктор модели данных сущности?

спасибо

4b9b3361

ОТВЕТЫ

Ответ 1

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

EFv4 с дизайнером

Плюсы:

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

Минусы:

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

Код EF сначала

Плюсы:

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

Минусы:

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

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