Почему я должен использовать Платформу Объекта по Linq2SQL

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

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

В то время как Linq ограничивается MS SQL Server.

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

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

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

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

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

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

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

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

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

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

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

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

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

pet.owner

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

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

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

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

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

Разделение классов и таблиц было бы действительно хорошим, если бы EF работал так, как они хотели.

Основная причина не для использования Linq2SQL заключается в том, что он имеет существенный недостаток имплицитного дизайна:

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

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

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

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

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