Entity Framework 6.0.2

Доступна новая версия библиотеки Entity Framework.

Что нового?

Исправлено 25 ошибок, влиявших как на производительность, так и на функциональность. Полный список можно посмотреть на CodePlex.

Как загрузить новую версию?

Для установки EntityFramework воспользуйтесь командой NuGet:

PM> Install-Package EntityFramework

Соответственно для обновления библиотеки в уже существующем проекте:

PM> Update-Package EntityFramework

Так же доступны инструменты Entity Framework для Visual Studio 2012 и 2013, которые необходимы только при использовании подходов Model First или Database First.

Комментарии (6) -

Алексей 14.12.2013 12:20:24

Жаль, что вы больше интересных статей про EF не пишете. С момента последней вашей серии про EF, там много чего изменилось/появилось, а в русском секторе только ваш блог наиболее полно освещал информацию Smile

@ Алексей: В планах исправлять ситуацию. К сожалению мало времени, поэтому сроки 100% обещать не могу. А вот освятить новинки EF6, может чуть запоздало, это думаю хорошая идея.

Интересно поддержку f# уже добавили туда?

Интересно, кто-нибудь, когда-нибудь задавался вопросом "уместности использования" ORM. Лично я в большинстве случаев, предпочитаю писать код, доступа к данным, старым дедовским способом - используя "чистый" ADO.NET. Приэтом не без грусти наблюдая тенденцию, что многие сейчас в своих приложениях предпочитают использовать ORM (не заморачиваясь с ADO.NET или вовсе не умея работать с ним).

Понятно что EF большую часть работы по написанию кода доступа к данным берет на себя, тем самым уменьшая время на кодирование, но кроме этого, она (EF) что-нибудь полезного еще делает? Что бы это полезное так скажем, сразу убедило начать использовать EF повсеместно в своих программах?

Microsoft не спит и постоянно совершенствует EF и это хорошо. Но меня по-прежнему не покидают вопросы сравнения производительности EF и "чистого" (если так правильно сказать) ADO.NET. Понятно, что все зависит от разных факторов, и сам EF для доступа к БД наверняка использует тот же ADO.NET. Проблема в том что EF это универсальное средство, так скажем "от всех бед", а раз оно универсальное, то наверняка будет не так быстрО.

Поэтому интересно, кто-нибудь вообще занимался подобного рода тестированием производительности при высокой нагрузке, что бы хотя бы примерную картину знать?

@ Pav: Уменьшение времени кодирования вам не достаточно? А возможности создать модели по БД или наоборот, БД по моделям. А миграции БД, в том числе автоматической?

Понятно, что вручную можно написать более оптимальные запросы, чем это делает EF. Но это уже получается преждевременная оптимизация. Ведь кто вам сказал, что конкретно этот запрос будет узким местом? К тому же, по мере их выявления таких мест, можно из оптимизировать, например, переписывая их на SQL.

Шамилль 17.09.2014 22:12:46

Добрый день. Именно при переписывании на sql столкнулся со следующим вопросом, как заставить Entity Framework считать из хранимой процедуры навигационные свойства?

Добавить комментарий