Я играл с EF, чтобы посмотреть, что он может обработать. Также многие статьи и сообщения объясняют различные сценарии, в которых EF может использоваться, однако, если вы пропустите сторону "con". Теперь мой вопрос: в каких сценариях я должен держаться подальше от Entity Framework?
Если у вас есть опыт в этом поле, скажите, какие сценарии не очень хорошо работают с EF. Расскажите мне о некоторых недостатках, с которыми вы столкнулись, когда захотели, что выбрали бы другую технологию.
Я также просто на "игре", и, хотя я был обеспокоен отсутствием встроенного агностицизма настойчивости, я был уверен, что будет "обход".
Фактически, даже не обход в архитектуре n-уровня.
WCF + EF
Если я правильно прочитал статью, я не вижу проблем с сериализацией сущностей по проводке (используя WCF) и также незнание персистентности не является проблемой.
Это потому, что я бы использовал PI в основном для модульного тестирования.
Тестирование единиц возможно! (я думаю)
В этой системе мы могли бы просто использовать макет службы (путем добавления вызова к сервису в классе на основе интерфейса ANOTHER, который может быть создан, например, из factory). Это проверит код нашего презентатора (нет необходимости в тестировании EF/DAL - это работа Microsoft!) Конечно, интеграционные тесты все равно потребуются для достижения полной уверенности.
Если вы хотите записать в отдельную базу данных, это будет сделано в слое DAL, который легко достигается через конфигурационный файл.
Моя ценность
Мое мнение - задумайтесь о EF и не откладывайте на всю эту гибель и мрак относительно этого, что делает раунды. Я бы предположил, что это будет какое-то время, и MS закроет ошибки в следующем году или около того. По словам Дэн Симмонс, ПИ определенно приходит.
EDIT: Я только что понял, что я прыгнул с пистолета, и, как хороший политик, на самом деле не ответил на вопрос, который был задан. К сожалению. Но я оставлю это, если кто-то найдет это полезным.
Голосование без доверия содержит несколько ошибок и/или недостающих функциональных возможностей в глазах тех, кто считает, что они знают, какие функции и их реализации, являются правильными для структур ORM/Datamapper.
Если ни одна из этих проблем не является для вас большой проблемой, я не понимаю, почему вы не должны ее использовать. Я еще не слышал, что это багги, которые взрываются влево и вправо. Все предостережения против него являются философскими. Я случайно согласен с вотумом недоверия, но это не значит, что вам следует. Если вам нравится, как работает EF, тогда идите. В то же время я бы посоветовал вам хотя бы прочесть вотум недоверия и попытаться получить рудиментарное понимание каждого из вопросов, чтобы принять взвешенное решение.
Вне этой проблемы и в основе вашего вопроса. Вам нужно следить за созданным Sql, чтобы вы могли делать хитрости до того, как проблема производительности попадает в производство. Даже если вы используете procs на бэкэнд, я все равно буду искать сценарии, в которых вы можете ударять по базе данных слишком много раз, а затем соответствующим образом переделывать свои сопоставления или выборки.
Одна потенциально большая проблема: Entity Framework 1.0 не поддерживает сохранение незнания. Это означает, что ваш бизнес-уровень зависит от вашего уровня доступа к данным.
Если все ваше приложение будет размещено в одном и том же процессе (например, на веб-сайте IIS), это не проблема.
Если, однако, вам нужно удалять ваши сущности (например, для клиента Silverlight или Windows Mobile), ваши объекты не будут легко сериализоваться по сети. Вам нужно будет создать отдельные классы передачи данных для отправки ваших сущностей через провод и дополнительную логику для маршалирования данных между классами сущностей и DTO.
Изменить: правописание.
Не все модели данных хорошо отображаются в приложениях Entities. Если сопоставление не является относительно простым, я бы пропустил Entity Framework. Вы обнаружите, что занимаетесь рукоделием, чтобы он работал без какой-либо явной выгоды.
У Андерса Хейльсберга были интересные комментарии об объектно-реляционном отображении здесь.
Поскольку EF не поддерживает POCO, может быть трудно написать хорошие модульные тесты. Это был один из ударов против него в Vote Of No Confidence.
Если вы хотите написать хорошие тесты, EF будет создавать препятствия. Вы можете обходить их, но это нетривиально.
Хотя оба SQL CE 3.5 SP1 и Entity Framework 4.0 Beta 1 поддерживают столбцы Identity Columns, используя эти два продукта вместе (по крайней мере, до перечисленных версий), столбцы Identity не поддерживаются. Вам необходимо будет установить первичные ключи самостоятельно.
Кроме этого, мне нравится EF с SQL CE.