Когда НЕ использовать Entity Framework

Question

Я играл с EF, чтобы посмотреть, с чем он может справиться. Также во многих статьях и постах объясняются различные сценарии, в которых можно использовать EF, однако если как-то упустить сторону «против». Теперь мой вопрос: , в каких сценариях мне следует избегать Entity Framework ?

Если у вас есть некоторый опыт в этой области, скажите мне, какие сценарии не подходят для EF. Расскажите мне о некоторых минусах, которые вы испытали, когда хотели, чтобы вы выбрали другую технологию.

Answer 1

вотум недоверия перечисляет несколько ошибок и / или пропущенных функциональных ошибок в глазах тех, кто считает, что знает, какие функции и их реализации подходят для сред ORM / Datamapper.

Если ни одна из этих проблем не имеет для вас большого значения, тогда я не понимаю, почему вы не должны ее использовать. Я еще не слышал, что это гадкий беспорядок, который взрывается влево и вправо. Все предостережения против этого являются философскими. Я согласен с мнением недоверия, но это не значит, что вы должны. Если вам нравится, как работает EF, тогда сделайте это. В то же время я бы посоветовал вам хотя бы зачитать вотум недоверия и попытаться получить элементарное понимание каждого из вопросов, чтобы принять обоснованное решение.

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

Answer 2

Одна потенциально большая проблема: Entity Framework 1.0 не поддерживает постоянное невежество. Это означает, что ваш бизнес-уровень зависит от вашего уровня доступа к данным.

Если все ваше приложение будет размещено в одном и том же процессе (например, веб-сайт на IIS), тогда это не проблема.

Если, однако, у вас есть необходимость в удалении ваших сущностей (например, к клиенту Silverlight или Windows Mobile), то ваши сущности не будут легко сериализироваться по проводам. Вам нужно будет создать отдельные классы передачи данных для отправки ваших сущностей по проводам и дополнительную логику для распределения данных между вашими классами сущностей и DTO.

Редактировать: правописание.

Answer 3

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

Фактически, это даже не обходной путь в n-уровневой архитектуре.

WCF + EF

Если я правильно прочитал статью , то я не вижу проблем с сериализацией сущностей по проводам (с использованием WCF), а также невежество в постоянстве не является проблемой.

Это потому, что я бы использовал PI в основном для юнит-тестирования.

Модульное тестирование возможно возможно! (я думаю)

В этой системе мы могли бы просто использовать фиктивную службу (заключив вызов службы в ДРУГОЙ класс, основанный на интерфейсе, который может быть произведен, например, на фабрике). Это будет проверять НАШ код презентатора (нет необходимости в модульном тестировании EF / DAL - это работа Microsoft!) Конечно, интеграционные тесты все равно потребуются для достижения полной уверенности.

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

Моя стоимость Таппенс

Мое мнение - составьте свое собственное мнение о EF и не отчаивайтесь от всех обречений и мраков в отношении того, что делает раунды. Я предполагаю, что это будет какое-то время, и MS устранит неисправности в следующем году или около того. По словам Дэна Симмонса, PI определенно приходит.

РЕДАКТИРОВАТЬ : Я только что понял, что бросил пистолет и, как хороший политик, на самом деле не ответил на заданный вопрос. К сожалению. Но я оставлю это на всякий случай, если кто-нибудь еще найдет это полезным.

Answer 4

Не все модели данных хорошо сопоставляются с сущностями приложения. Если сопоставление не является относительно простым, я бы пропустил Entity Framework. Вы обнаружите, что делаете стойку на руках, чтобы она работала без какой-либо явной выгоды.

У Андерса Хейлсберга было несколько интересных комментариев об объектно-реляционном отображении здесь .

Answer 5

Поскольку EF не поддерживает POCO, может быть сложно написать хорошие модульные тесты. Это был один из ударов против него в вотум недоверия .

Если вы хотите написать хорошие тесты, EF будет создавать препятствия. Вы можете обойти их , но это нетривиально.

Answer 6

Хотя и SQL CE 3.5 SP1, и Entity Framework 4.0 Beta 1 поддерживают столбцы идентификаторов, используя эти два продукта вместе (по крайней мере, до перечисленных версий), столбцы идентификаторов не поддерживаются. Вам нужно будет установить первичные ключи самостоятельно.

Кроме этого, я наслаждаюсь EF с SQL CE.