Работаю сейчас над двумя проектами на C#, где есть базы данных с кучей хранимых процедур, а для доступа к данным используются какие-то обёртки для выполнения этих самых процедур. Один проект — legacy, второй свеженаписанный.

Оно как бы работает, но есть определённые проблемы. Из наиболее значимых проблем — трудности написания юнит-тестов для хранимых процедур (на данный момент, если не ошибаюсь, у нас нет ни одного юнит-теста для SQL-кода) и сложность поддержки и развития всего этого великолепия. Сейчас на legacy-проекте есть полтора разработчика, которые хорошо ориентируются в имеющихся SQL-процедурах, а для остальных (и меня в том числе) любое исправление логики в SQL выливается как минимум в час раскуривания, "а как же оно работает". Размеры хранимых процедур достигают нескольких сотен строк, внутри там бывает десяток JOIN'ов, CROSS APPLY и прочих премудростей, которые при беглом прочтении кода понять трудно. История последних найденных багов показывает, что SQL-код исправлять приходится довольно часто (бизнес-правила часто меняются и добавляются), а делать это сложно и долго.

Хочу предложить коллегам мигрировать на Entity Framework. С тем, чтобы сначала использовать его для вызова имеющихся хранимых процедур и постепенно, по мере доработки кода, переписывать хранимые процедуры на LINQ-запросы. Ну это чтобы не ломать то, что есть и не тратить полгода на переписывание с нуля. Чтобы миграция была плавной и наименее болезненной. Сейчас готовлю документ с моими предложениями и описанием предлагаемой процедуры миграции. В конце хочется полностью избавиться от бизнес-логики в SQL-коде. Это в идеале.

Так вот. Плюсы использования Entity Framework'а я примерно знаю. А какие у него есть минусы? Какие могут быть доводы против использования Entity Framework? Я слышал, что он несколько уступает по производительности прямым SQL-запросам, но разница исчисляется единицами процентов — пару-тройку процентов производительности мы можем принести в жертву плюсам этого фреймворка. Если где-то будет сильно хуже, то там может оставить пару-тройку хранимых процедур и вызывать их через EF. Юниттестирование с ним тоже не столь просто, но хотябы решаемо — мне уже приходилось писать подобие юнит-тестов для EF, где использовалась временная база данных на реальном SQL-сервере. Это работает, но медленно. А поиски по интернету показывают, что для EF можно создавать базы в памяти — например, используя SQLite.

Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?