Почему я должен использовать Entity Framework поверх Linq2SQL

Question

Чтобы быть ясным, я не прошу параллельное сравнение, которое уже задавалось Ad Nauseum здесь, на SO. Я также не спрашиваю, умер ли Linq2Sql, так как мне все равно. То, что я спрашиваю, это ....

Я создаю внутренние приложения только для некоммерческой организации. Я единственный разработчик в штате. Мы ВСЕГДА используем SQL Server в качестве нашей базы данных. Я также проектирую и строю базы данных. Я пару раз успешно использовал L2S.

Принимая все это во внимание, может ли кто-нибудь предложить мне убедительную причину использовать EF вместо L2S?

В эти выходные я был в Code Camp , и после часовой демонстрации EF, которую я мог сделать в L2S, я задал тот же вопрос. Спикеры ответили: «L2S мёртв…». Хорошо! НЕ! ( см. Здесь )

Я понимаю, что EF - это то, что MS ХОЧЕТ нам использовать в будущем ( см. Здесь ), и что оно предлагает гораздо больше опций настройки. Что я не могу понять, так это то, должно ли что-то для меня иметь значение в этой среде.

Одна конкретная проблема, с которой мы столкнулись, заключается в том, что я унаследовал базовое приложение, которое было построено на 4 разных базах данных SQL. У L2S с этим большие трудности, но когда я спросил вышеупомянутого оратора, поможет ли мне в этом EF, он сказал «Нет!»

Answer 1

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

Answer 2

У меня есть большая причина , а не , чтобы использовать Linq2SQL, что она имеет существенный недостаток дизайна:

Рекомендуемая лучшая практика использования DataContext - использовать его в недолговечном стиле «единицы работы». Великолепно, за исключением того, что это умеренно дорогой объект, который нужно постоянно создавать и утилизировать.

Загвоздка возникает, когда вы хотите десериализовать или воссоздать объект (возможно, с отправленной веб-страницы), а затем обновить существующую запись. Метод Attach, предлагаемый Linq-to-sql, принимает только следующие три сценария:

1. Вы применяете временные метки на всех ваших таблицах.
2. Вы повторно выбираете объект, который хотите изменить, затем меняете его и отправляете.
3. У вас волшебным образом все еще остается оригинальная версия объекта вокруг.

Первый сценарий требует изменений базы данных, что для некоторых сред недопустимо. Второй сценарий совершенно неэффективен - зачем извлекать данные, которые у вас уже есть? Третий сценарий нереалистичен - веб-приложения без сохранения состояния обычно не сохраняют историческую информацию.

Суть здесь в том, что ... EF4.0 позволяет вам повторно присоединить объект к ObjectContext и пометить его как добавленный или новый, и контекст соответствующим образом сгенерирует правильный оператор INSERT / UPDATE.

Answer 3

Я часто задавался вопросом об этом сам, поскольку EF, кажется, добавляет много сложности по сравнению с L2S. Поскольку MS активно разрабатывает EF, есть некоторые новые аспекты EF 4, которые, возможно, стоит проверить. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * [1].

В частности, я лично заинтересован в поддержке POCO и шаблона репозитория, поскольку они хорошо подходят для проектов, над которыми я работаю. По моему мнению, одна из веских причин для использования какого-либо конкретного поставщика заключается в том, насколько легко будет в будущем переключиться на совершенно другого поставщика (конечно, без перестройки всего кода приложения). Я обнаружил, что L2S не хватает в этом отношении (во всяком случае, из коробки), и я рад видеть изменения в EF 4. Однако до сих пор я только читал об этих изменениях в EF 4, поэтому я могу: не сказать, насколько хорошо они на самом деле работают на практике.

Answer 4

EF ориентирован на полную ORM, где ваша объектная модель значительно отличается от вашей схемы БД. L2S больше ориентирован на быстрый генератор DAL.

Проблема в том, что EF - посредственный ORM, а L2S - действительно отличный генератор DAL.

Я бы сказал, если L2S соответствует вашим потребностям, оставайтесь с ним и не позволяйте маркетингу MS подтолкнуть вас. Если L2S не делает то, что вам нужно, и вам нужно оставаться в продуктах Microsoft, переходите на EF. Если у вас есть немного свободы над своей технологией, посмотрите на NHibernate и LLBGen (imo оба лучше, чем EF)

Answer 5

Они оба очень глючные. Я обнаружил 8 ошибок в Entity Framework с тех пор, как начал использовать его месяц назад (два влияют на L2S, по крайней мере три все еще присутствуют в EF4). Это был один из самых болезненных событий в моей жизни.

Хотя разделение классов и таблиц было бы очень хорошо, если бы EF работал так, как они этого хотели.

Answer 6

Я задал себе этот вопрос, когда впервые увидел EF, и я уже написал большое приложение на Linq2Sql. Самое большое изменение сделано в слое отображения объектов. В EF отношения и навигация управляются для вас. Поэтому, если у меня есть две таблицы, которые имеют отношение внешнего ключа (скажем, Домашние животные и Владельцы), я могу сделать

pet.owner

тогда как в L2S мне пришлось бы самому написать запрос на соединение. Отображения «многие ко многим» прекрасно обрабатываются в том смысле, что если у вас есть «чистая таблица соединений» (то есть таблица с двумя внешними ключами и без других данных), то эта таблица не будет представлена ​​в сопоставлениях объектов.

Вы также можете справиться с энергичной / ленивой загрузкой самостоятельно.

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

В целом я предпочитаю EF, но YMMV

Answer 7

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

Если только вы и у вас нет времени изучать EF, придерживайтесь Linq2Sql. Но если у вас есть время и вы думаете, что в конечном итоге вам могут потребоваться другие формы наследования, кроме -per-table или любой другой функции EF, сделайте это!

И причина № 1, по которой вы должны переключиться: опыт Entity Framework будет хорошо смотреться в вашем резюме!

Answer 8

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

См. http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx

Answer 9

Entity Framework обладает лучшей совместимостью, если вы ожидаете, что ваше приложение будет масштабироваться на других СУБД, это одно из его главных преимуществ.

Entity Framework будет работать на СУБД, отличной от Microsoft SQL Server, например, Oracle, MySQL и т. Д.

Хотя Linq ограничен MS SQL Server.

Answer 10

Ну, в конце зависит от реквизитов.

Теперь вы используете linqtosql, и он подходит вам, но, возможно, однажды у вас появятся более сложные реквизиты, которые вы сможете лучше выполнить с EF. Например, используя скорость или что-то еще.