Как излишество .net Entity Framework по сравнению с LinqToSql?

Исправьте меня, если я неправ, но платформа объекта должна только сыграть роль, когда необходимо преобразовать объекты бэкенда, как то, когда Вы комбинируете таблицы от различных источников данных, разделяя таблицы, и т.д. Это добавляет слой объекта, таким образом, можно скрыть всю инфраструктуру и просто иметь дело с очищенными объектами. Если Вы просто используете его 1 для 1 против Ваших таблиц как Вы, был бы в LINQ к SQL, то я уверен, что слой сложности, которую Вы не используете, замедлит его. Это кажется, что LINQ к SQL является правильным инструментом для правильного задания в Вашем случае, пока у Вас нет более сложных потребностей источника данных.

Linq к SQL и Платформе Объекта являются концептуально различными зверями, и необходимо сделать выбор на основе того, как они соответствуют потребностям, а не на микросравнительных тестах. Даже если Платформа Объекта была медленнее, это - фокус команды ADO.NET в Microsoft и будет много раз улучшаться. Linq-SQL эффективно замораживается.

Концептуально они отличаются в том Linq-SQL, просто способ выполнить использование запросов базы данных Linq. Звучит достаточно очевидным, но точка: Вы получаете доступ к данным, структурированным согласно модели базы данных его. Хотя FKs являются trasformed соответственно, у Вас все еще есть избыточные объекты, где данные были нормализованы в различные таблицы. Каждый запрос, который Вы пишете, должен справиться с такой вещью.

Платформа объекта позволяет Вам декларативно создавать слой, который представляет Ваши данные путем, это должно быть представлено в памяти, принеся данные из нескольких таблиц в отдельный объект где approriate; представление many-many отношения как свойства набора, и т.д. И запросы, которые Вы пишете затем, будут к этой модели и будут намного более чистыми и более очевидными в цели (больше никакой 15 соединений таблицы!).

У O'Reilly есть всесторонняя книга, выходящая Платформа Объекта на 15-м Januray 2009 (предварительный просмотр, доступный теперь на Roughcuts), если Вы не уверены в использовании Платформы Объекта - документация MSDN для него действительно в значительной степени сосет в данный момент, который делает предложение его еще тяжелее. Я действительно полагаю, что это стоит использовать в длительный период для всех кроме самого тривиального из проектов (и лично если бы я писал что-то тривиальное, то я просто использовал бы СУМАТОХУ NET2 непосредственно и забыл бы о Linq).

Прежде чем Вы погрузитесь в к Linq К SQL, проверите эту статью ее диспетчера программ. Он ставит простой вопрос "LINQ, к Мертвому SQL?" Ответ не так прост. Это - определенно не "нет". Звуки мне больше как, "вероятно, возможно".

Я предложил бы прежде, чем погрузиться в к EF (теперь названный Linq К Объектам), Вы серьезно рассматриваете NHibernate, но это - моя персональная предвзятость.

Однако будьте осторожны, LinqToEntities может делать некоторые действительно интересные вещи, если вы используете запросы, например, с группировкой по. Мне никогда не удавалось заставить LinqToEntities преобразовать группу с помощью в фактическую группу SQL с помощью, вместо этого он генерирует несколько массивных блоков кода, которые могут быть действительно неэффективными.

Например, перейдите по следующей ссылке: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85- 31d0b6a85f68

Если вы пытаетесь написать «нетривиальные» запросы, ObjectQuery.ToTraceString () - ваш лучший друг, чтобы убедиться, что EF не делает что-то действительно глупое за вашей спиной.

Почему бы просто не выполнить обычный SQL-запрос с помощью SqlDataReader и не привязать их к универсальному списку. Похоже, что SQL намного более гибкий и мощный, чем любой ORM. В любом случае на практике !! SQL мертв? И это должен быть самый быстрый подход, и обратная сторона - строки sql, но вы работаете ближе к металлу и чувствуете, что у вас гораздо больше контроля, чем при использовании любого ORM. Похоже, что в ORM: s всегда есть какая-то ошибка, что делает более сложные запросы головной болью и требует намного больше времени для написания, чем если бы вы выполняли их на простом SQL. Или это только я новичок в ORM: s?