Должны ли мы использовать Entity Framework?

31

В настоящее время у нас есть следующий стек:

  • VS 2005
  • Веб-формы
  • SQL Server 2005
  • IIS 6

Мы планируем перейти на это:

  • VS 2010
  • MVC и веб-формы
  • SQL Server 2008
  • IIS 7

Мой вопрос: когда мы перейдем на MVC с VS 2010, должны ли мы использовать Entity Framework (или другой ORM), микро ORM (например, Massive ) или просто обычный SQL?

Все учебные пособия, которые я читал о VS 2010, направлены на использование Entity Framework для транзакций данных, но будет ли это в обозримом будущем (5+ лет)?

Если это имеет значение, приложения нашего клиента могут иметь от 10 до 1000 активных пользователей.

guanome
источник
Вы используете Linq-to-SQL в настоящее время?
Морган Херлокер
Мы используем параметризованный SQL
guanome
4
Избегайте использования SQL непосредственно в будущем. ORM или EF почти обязательны. Посвятите какое-то время стратегии своего уровня доступа к данным. Это критическое решение, и это не тривиальная задача. Удостоверьтесь, что у вас и у команды достаточно времени, чтобы изучить это. Внедрение новых основных технологий в команде должно быть управляемым. Выберите инструмент, выберите материал, получите образование, ..., затем оцените и решите.
NoChance
2
Новые или существующие базы данных? Потенциально существует огромная разница между созданием новой БД с учетом соглашений EF и попыткой дооснастить EF поверх существующей БД, которая не была создана для ORM.
rmac
@rmac Это было для новой базы данных.
Гуаном

Ответы:

45

Недавно я перешел от использования встроенных SQL-запросов к использованию EF, и вот что я нашел:

Pros

  • Гораздо быстрее построить DAL (люблю не писать запросы SQL!)
  • Гораздо проще поддерживать
  • Больше не нужно помнить, чтобы проанализировать мой ввод перед построением встроенного оператора SQL, что означает меньшую вероятность атаки SQL-инъекцией (конечно, это все еще возможно в зависимости от ваших запросов, но гораздо менее вероятно)

Cons

  • Не может охватить несколько баз данных ... по крайней мере, не легко
  • Всем сущностям (таблицам, представлениям и т. Д.) Нужен первичный ключ
  • Если вы хотите обновить один столбец в таблице более 100 обязательных столбцов (не мой дизайн таблицы), вам нужно развернуть все 100 столбцов, чтобы выполнить обновление. Или используйте хранимую процедуру.
  • У меня были проблемы с некоторыми значениями по умолчанию, определенными на сервере SQL, которые не добавляются в модель сущностей после добавления новой записи. Обычно это с вычисленными значениями или значениями, которые добавляются в триггер INSERT
  • Иногда SQL-запросы плохо пишутся и выполняются медленно. Если у вас медленный запрос, запустите трассировку SQL, чтобы увидеть, что делает EF. Возможно, вы сможете заново обработать этот запрос как SP или View. Это случается не так часто, хотя.
  • У меня было несколько проблем с попыткой создать связь между таблицами, для которых внешний ключ не определен в SQL Server. Обычно это потому, что я пытаюсь создать 1:0-1отношения, в которых EF хочет использовать1:0-*

Я не эксперт по EF, поэтому я, вероятно, пропустил некоторые вещи. Это только те элементы, которые я знаю в прошлом при переходе от встроенного SQL к Entity Framework. Я рад, что сделал такой переход, но были времена, когда я действительно ненавидел EF из-за его причуд.

Рейчел
источник
7
+1 за подробный и организованный ответ. «Все сущности (таблицы, представления и т. Д.) Нуждаются в первичном ключе» звучит как разумное ограничение, а не как мошенничество.
NoChance
2
@EmmadKareem Это нормальное ограничение, если у вас есть контроль над базой данных, но если вы работаете со сторонней базой данных или с представлениями, это может быть немного раздражающим
Рэйчел
1
Просто попробуйте использовать EF в отключенном веб-приложении N-Tier - обновление сущностей в сеансе и отношениях ММ, хммммм, какое удовольствие!
Видар
5
Сущности @EmmadKareem действительно нуждаются в единственном значном первичном ключе - использование составных ключей - кошмар в EF. Это скорее мошенничество, чем разумное ограничение.
Кирк Бродхерст
1
Я бы сказал, что безопасность - это еще одна проблема. Многие считают, что весь доступ к БД должен проходить через хранимые процедуры с ролями БД, связанными с процессами, чтобы определить, какие логины могут выполнять какие хранимые процессы. Это исключает EF / LINQ для создания запросов. Я использовал EF , но наткнулся клиенты ( кашель Microsoft) , которые имели эти требования безопасности
Mick
12

Entity Framework - это инструмент для повышения производительности. Если у вас нет веских причин не делать этого (например, вы используете SQL 2000 или у вас нет времени на освоение этой технологии), используйте лучшие инструменты, которые есть в вашем распоряжении.

При этом я считаю, что концепция сущностей очень хорошо переводится в модель модели MVC. Несмотря на то, что отношения 1: 1 с моделями и таблицами являются плохой практикой, размышления с точки зрения сущностей, как правило, приводят к чистым проектам, легко читаемому коду (особенно с LINQ).

Entity Framework активно поддерживается Microsoft. Ни у кого нет волшебного хрустального шара, чтобы сказать «поддержка продлится Х лет». Я не вижу причин полагать, что Сущность умрет в следующие 5 лет.

P.Brian.Mackey
источник
3
LinqToSql умер довольно быстро, поэтому на самом деле нет оснований полагать, так или иначе, выживет ли Entity Framework. Стоит принять во внимание новый толчок MS к Metro, поскольку они рассматривают возможность пересмотра многих своих предложений.
ocodo
3
Сломохо, может быть, у вас есть другое определение слова «мертвый» из остального мира. Потому что LinqToSql просто активно не разрабатывается. Вы по-прежнему сможете использовать его через 10-20 лет.
Борис Янков
4

Другим потенциальным решением является использование альтернативной библиотеки Entity Framework, отличной от поставляемой с VS. В Интернете есть несколько таких.

Концепция структуры уровней Entity / 3 существует уже некоторое время и работает с несколькими пользовательскими библиотеками, как и многие другие разработчики, до того, как Microsoft выпустила свою собственную «официальную» среду.

Pros

Воспользуйтесь преимуществами инфраструктуры Entity (DAL), не застревая с постоянными изменениями библиотек / структур Microsoft.

Добавление в библиотеку функций, которые могут быть недоступны существующей официальной библиотеке, например, использование нескольких брендов dtabase.

Cons

Приходится поддерживать библиотеку или инструменты. Очень распространено иметь инструмент кода Entity Generator для генерации enitites.

umlcat
источник
Я нахожу этот ответ очень запутанным. Существует только одна Entity Framework (с заглавными буквами), которую Microsoft производит. Вы имеете в виду «использовать другой объект реляционного картографа»? Entity Framework - это не общий термин, это название ORM от Microsoft.
NickG
Хотя существует Microsoft Entity Framework, концепция Entity Framework существует уже несколько лет.
umlcat
3

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

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

Том Сквайрс
источник
3
+1 за рекомендацию не переписывать рабочий код.
NoChance
2

В вашей ситуации я бы определенно использовал Entity Framework, я обнаружил, что он хорошо работает с MVC.
Вот некоторые реальные причины и указатели.

  • Linq приятно использовать, и отложенное выполнение также чрезвычайно полезно.
  • Вы можете создавать свои модели (однако при использовании с mvc я рекомендую использовать модели представлений в сочетании с моделями данных, это значительно упрощает проверку и привязку моделей, если вы применяете такой подход, используйте automapper, чтобы отобразить изменения обратно на ваш модель данных).

Однако есть несколько вещей, которые вам необходимо узнать об использовании ORM.

  • Что контекст делает для вас (отслеживание сущностей)
  • Что контекст должен использоваться как единица работы
  • Не забывайте о параллелизме, EF может сказать вам, когда ваш объект устарел, но это может быть сложно, если вы хотите правильно обрабатывать параллелизм между запросами (так как вам нужно сохранить временную метку или что-то в этом роде).

Что нужно учитывать

  • Триггеры и ORM не работают вместе, вместо этого используйте события ORM.
  • Убедитесь, что все ваши таблицы имеют предварительные ключи.

Я также очень рекомендую подход «сначала код», даже если у вас есть существующая база данных.

  • Соглашения означают, что вам не нужно повторно отображать сопоставления или классы при изменении базы данных.
  • Проще разместить валидацию и другую логику в моделях.
  • Вы можете использовать генератор кода, чтобы помочь сделать их, если у вас есть огромная база данных.
Даниэль Литтл
источник