Данный пост навеян долгожданным релизом EF и нашумевшим ADO .NET Entity Framework Vote of No Confidence. В целом, критика EF достаточно грамотная и заслуженная. Первую версию EF действительно не стоит считать волшебной палочкой, которая сможет мало того, что решить ваши проблемы, но еще и удовлетворить всех желающих цветом, формой и набором заклинаний. Однако, это достаточно полноценный и на удивление малобажный ORM (баги дизайнера в бета-версии, думаю, не в счет, они уже почти все пофикшены), который уже сейчас можно использовать. Если есть желание, конечно. А желание можно подкрепить вот этим ответом на Vote of No Confidence. Из своего полугодового опыта работы еще с бетой 3 могу лишь добавить, что я считаю реальной проблемой лишь 3 пункта: отсутствие lazy loading, Anemic Domain Model anti-pattern и действительно заколебавший designer-код в edmx-файле, который создает проблемы с мержем. Lazy loading мы пофиксили при помощи custom tool и CodeDOM (если интересны подробности, вам сюда, сюда или даже сюда), который встраивается в pipeline и генерирует нам cs-файл с сущностями, поддерживающими ленивый образ жизни. С Anemic Domain Model не все так просто и лично меня беспокоит проблема написания unit-тестов для сущностей EF. Впрочем, анализ этой проблемы мы пока оставим до лучших времен, а для большинства задач подойдут partial-классы или кодогенерация. Дизайнер в SP1 значительно улучшился, в нем пофиксили часть надоевших багов, но, насколько я знаю, секцию designer из edmx-файла пока не вынесли. Подождем.
Резюмируя, могу сказать, что в целом Entity Framework уже сейчас оправдывает ожидания и позволяет решать широкий спектр задач. Конечно, он не лишен недостатков, но меня радует тот факт, что MS начала прислушиваться к мнению community и сделала процесс дизайна следующей версии более открытым (добро пожаловать на блог EF Design), а не просто делает что-то за ширмой. Фактом является также и то, что EF будет развиваться, в отличие от того же Linq to SQL, который стоит использовать лишь для небольших приложений. Так что сейчас у нас уже есть реальная альтернатива стандартной модели работы с данными ADO.NET. В приложении критичен performance, вы разрабатываете социальную сеть или электронный магазин – вам лучше использовать старый дедовский способ, важна скорость и удобство разработки – берите ORM: NHibernate, Active Record, EF или что-то еще. Пишете небольшое приложение – к вашим услугам Linq to SQL или даже ActionPack. Кому интересно узнать про EF подетальнее, рекомендую подкасты с Julie Lerman (на .NET Rocks), Daniel Simmons (про релиз v1 и вообще на .NET Rocks) и Mike Pizzo (на Hanselminutes), а также блоги все той же Julie и Daniel.
Саша, и откуда ты взял что
ReplyDelete>> Фактом является также и то, что EF будет развиваться, в отличие от того же Linq to SQL, который стоит использовать лишь для небольших приложений.
Меня интерисует та часть что про Linq to SQL.
Большое спасибо за исчерпывающую заметку.
ReplyDeleteМеня тоже, как и Майка, интересует почему ты считаешь тчо Linq to SQL подходит только для небольших приложений?
Если у меня в приложении будет очень сложные запросы, то я могу вынести их в хранимые процедуры, после чего в моем DataContext классе это будет выклядеть как один обычный метод, возвращающий нужную мне структуру данных.
Очень хотелось бы увидеть пост, посвященный NHibernate и Active Record. Насколько эти технологии удобны использовать, что понравилось, что не понравилось?
Насколько я знаю Active Record построен на основе NHibernate. Для себя до сих пор не выяснил зачем одну ORM строить поверх другой :)
Послушай подкаст с Julie, она там говорит, что Linq to SQL развиваться, скорее всего, не будет. Она также сказала, что на Linq to SQL особой ставки в плане корпоративных приложений не делается, для этого есть EF. Кроме того, я уже неоднократно читаю, что EF идет "на смену" традиционной ADO.NET. Конечно, этого не произойдет еще долго, т.к. EF по производительности пока далеко до хранимых процедур и оптимизатора SQL Server, но направление понятно. Насколько я понимаю всю эту кухню, через Linq to SQL они обкатывали ORM-технологию и генератор SQL, а также вообще применение linq на чем-нибудь серьезном. Теперь linq'ов уже куча, язык путешествует сам по себе, а обкатанные технологии они внедряют в EF. Где-то так, хотя, конечно же, я могу ошибаться в своих выводах. Думаю, в linq to sql они будут добавлять функциональность по запросам community, но это явно уже не приоритетное направление.
ReplyDeleteПрошу прощения за пустой пост, забыл подписаться на комментарии :(
ReplyDeleteЛеш, частично на твой вопрос ответил в ответе Мише :) Насчет сложных запросов и всего остального - конечно, ты можешь писать любое приложение с использованием linq to sql. Но EF уже сейчас предлагает намного более расширенный функционал по сравнению с linq to sql. Как минимум, это разделение модели на концептуальную и модель данных с маппингом между ними, что позволяет с легкостью портировать приложение с одной базы на другую, не меняя код. Благодаря этому маппинг сущностей на базу становится более гибким, мы можем из одной таблицы сделать тучу сущностей, из одной сущности - тучу таблиц, использовать наследование, сложные типы и т.д. Кроме того, EF предоставляет расширенную модель работы с контекстом и некоторые другие вкусности. А после выхода поддержки POCO (plain objects CLR objects) и, соответсвенно, генерации базы по коду, а не наоборот, linq to sql будет точно отдыхать.
ReplyDeleteНасчет NHibernate и Active Record и их сравнения с EF ничего, к сожалению, сказать не могу. Могу лишь посоветовать ссылку на блог Юры Скалецкого - он сравнивал EF с некоторыми другими ORM. Лежит тут - http://yuryskaletskiy.blogspot.com/2008/07/net-orm.html
2alexey diyan
ReplyDelete>> Насколько я знаю Active Record построен на основе NHibernate.
>> Для себя до сих пор не выяснил зачем одну ORM строить поверх другой :)
Для того, чтобы не морочить себе голову с hibernate mapping-ом. Расставил атрибуты и готово :)
>>Послушай подкаст с Julie
ReplyDeleteLINQ to SQL, you know,
Microsoft's guidance on LINQ to SQL is it's for RAD
development and not for big enterprise projects. So,
if you're doing that kind of work where you need all of
that control, it's probably not for you anyway.
Правда я бы учитывал что это слова консультанта...
И все же мое ИМХО, я бы не стал настолько категорично делать такие заявления.
Например я еще не видел ситуаций когда потдерживать маппинг на другую струтуру БД дешевле чем проапгредить слой доступа к данным. А все остальные фкусности что ты описал доступны или планируються и для Линка В Скуль.
Миш, возможно, слова действительно необоснованно громкие были. Я был прав как минимум в том, что EF будет развиваться, и что Linq to SQL стоит использовать для RAD, не enterprise, приложений. Будет ли развиваться Linq to SQL или нет - время покажет. Я пока что не видел ни планов на будущее, ни списка новых фич. Если ты видел что-то подобное или список того, что перекочует из EF в Linq to SQL - кинь ссылки или информацию. Может, я что-то просмотрел. Я лишь просто делаю выводы на основании данных, которыми располагаю. У меня пока что в голове слабо укладывается, как в Linq to SQL можно внедрить POCO и стоит ли вообще это делать. Да и поддержки гибкой database-independance там тоже не будет. ОЧЕНЬ все это сомнительно, в общем. Да и глупо делать два почти одинаковых продукта, отличающиеся лишь способом описания модели.
ReplyDelete