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

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

• 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 активных пользователей.

Недавно я перешел от использования встроенных 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 из-за его причуд.

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

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

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

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

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

Pros

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

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

Cons

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

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

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

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

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

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

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

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

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

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

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