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

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

есть 2 типа использования poco с EF 1. с помощью конструктора сущностей 2. с использованием только кода

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

Благодарность


person oliver.sakkam    schedule 23.02.2011    source источник
comment
[OT] вы также можете использовать NHibernate, и вам не придется идти на компромиссы :-)   -  person Diego Mijelshon    schedule 23.02.2011
comment
@Diego: Просто любопытно - что именно вы имеете в виду? Насколько я помню, nHibernate позволяет определять сопоставления в xml, а также в коде (свободный nHibernate) - в основном те же параметры, что и в EF. Так каких компромиссов вы говорите избегать?   -  person Yakimych    schedule 23.02.2011
comment
@Yakimych: с NHibernate ваш выбор метода и инструментов сопоставления не ограничивает доступные функции.   -  person Diego Mijelshon    schedule 23.02.2011
comment
@Diego: К сожалению, иногда вам приходится иметь дело с глупой политикой компании, которая гласит: нет NHibernate, нет открытого исходного кода и т. Д.   -  person Ladislav Mrnka    schedule 25.02.2011
comment
@LadislavMrnka: всегда есть careers.stackoverflow.com :-)   -  person Diego Mijelshon    schedule 25.02.2011


Ответы (1)


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

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

Плюсы:

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

Минусы:

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

Сначала код EF

Плюсы:

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

Минусы:

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

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

person Ladislav Mrnka    schedule 23.02.2011
comment
Вы выполнили все, что я бы сказал в своем ответе. Я бы только добавил веса комментарию, не очень хорошему для больших моделей. 50 таблиц - это небольшая модель, но вы абсолютно правы, она действительно выглядит грушей около 50. И это кошмар в среде с несколькими разработчиками. Я начал использовать CTP5, даже с учетом минусов, потому что подозреваю, что они будут сделаны задолго до меня, и в настоящее время думают, что ctp5 - это последний выпуск, прежде чем он будет закреплен. - person Ralph Shillington; 23.02.2011