Saturday, November 1, 2008

Будущее LINQ to SQL и Entity Framework

В одном из своих постов я имел неосторожность высказать мнение, что Entity Framework будет активно развиваться, а L2S (LINQ to SQL) – вряд ли, и что акцент разработки будет переведен на Entity Framework. К сожалению, мои опасения, похоже, становятся реальностью: Tim Mallalieu, Product Manager LINQ to SQL and LINQ to Entities сначала написал в блоге ADO.NET, что, цитирую:

«We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well»

А потом, в ответ на кучу комментариев о том, что «WTF? LINQ to SQL is dead?» он сделал дополнительный пост с разъяснениями, в которых повторил свои предыдущие слова, но постарался смягчить выражения:

«As mentioned, we have been working on this decision for the last few months. When we made the decision, we felt that it was important to immediately to let the community know. We knew that being open about this would result in a lot of feedback from the community, but it was important to be transparent about what we are doing as early as possible. We want to get this information out to developers so that you know where we’re headed and can factor that in when you’re deciding how to build future applications on .NET»

Так что, да, L2S будет жить и даже немного развиваться, но не с такой скоростью и не с такими инвестициями, как Entity Framework. Похоже, Microsoft сделала ставку на более тяжеловесный, но функциональный ORM. В свете последнего опроса на сайте того же Скотта Хенселмана, где оказалось, что L2S пользуется в 3 раза больше людей, чем EF, и по популярности он сравнялся с каличными датасетами, это решение выглядит немножко странным. С другой стороны, не стоит забывать, что L2S с нами уже почти год, на EF зарелизился только месяц назад. Я же считаю, что Microsoft нужно бы продолжать развивать L2S с прицелом на легковесность и производительность. Entity Framework – это, конечно, здорово, но все дело в том, что есть целый класс веб-приложений, в которых производительность превыше всего. Это, в первую очередь, сайты для массового обслуживания пользователей: электронные магазины, социальные сети, форумы и др. А здесь Entity Framework, увы, совсем не рулит. Кроме того, L2S можно рассматривать как реальную альтернативу датасетам, которые до сих пор используют многие. На деле же получается, что своим решением и маркетинговой политикой Microsoft может просто оставить L2S без существенной поддержки, а нас с вами – без мощного инструмента для быстрой работы с базой. Неужели придется возвращаться к DataReader'ам? :)

PS. Присмотритесь внимательнее к чарту с результатами опроса: ASP.NET MVC, который еще в бете, УЖЕ пользуется внушительное количество людей. Конечно, выборка не репрезентативна, так как Скотт работает в MVC тиме, и на его блог люди приходят целенаправленно, чтобы что-то узнать об этой технологии, но все же уже неплохо :)

Upd. Nov 9. Джули Лерман (Julie Lerman) дала дополнительные комментарии по этой теме здесь. В частности, она рассказала, откуда у Microsoft появилось 2 похожих ORM. Меня вот тоже волновал всегда этот вопрос :)

"LINQ to SQL grew out of the C# team. At the same time, the Data team was working on the EDM and Entity Framework. When both technologies were presented, it was a bit of a shock for each team to see that they had to products that, on the surface, were similar."

И еще пара слов о том, почему все-таки выжил Entity Framework:

"Eventually, LINQ to SQL became part of ADO.NET (it is a Data Access feature after all) and was handed over to the ADO.NET team. It wasn't the happiest of occasions for it's creators since the writing seemed already to be on the wall."

Видите, как все просто :)

5 comments:

  1. Накаркал ;)

    ReplyDelete
  2. Несколько запоздалый камент, но все же.
    Не пойму, почему это DataSet'ы (тем более Typed) - каличные? С моей точки зрения, это довольно эффективный инструмент в случаях простой бизнес логики. Как раз для быстрой разработки электронных магазинов. К тому же, как пишет в своей книге Фаулер, DataSets идеально ложатся на pattern Table Module.
    Сам неоднократно применял DS и в ряде случаев они показывают себя лучше чем LTS. Например, заполнение DataSet через Stored Procedures работает куда как быстрее, чем длинные SQL-запросы сгенерированные LTS.

    ReplyDelete
  3. Да, несколько запоздало и немного не по основной теме :) Сразу оговорюсь, что есть ситуации когда использование датасетов (типизированных, у нетепизированных все же слишком много недостатков) более оправданно, чем использование датаридеров и своей объектной модели. Но недостатки датасетов в совокупности с желанием иметь более чистый и управляемый код обычно перевешивают. Почему мне больше нравится использовать датаридеры + свою модель:

    1) Архитектура. Датасеты больше подходят для реализации анемичной модели, в них сложно запихнуть логику, а я предпочитаю, чтобы логика, относящаяся к сущностям, им же и принадлежала. Типизированные датасеты тоже позволяют добавлять логику, но они все равно склоняют тебя к использованию database-centric architecture.
    2) Производительность. Датаридеры быстрее работают. В веб-приложениях это часто критично. Кроме того, даже если тебе нужно вытащить одну запись, то в случае с датасетом это будет стоить намного дороже, как с точки зрения времени, так и с точки зрения памяти. Собственные объекты легковеснее.
    3) Гибкость. Маппинг базы данных на датасет менее гибок, чем маппинг на собственные сущности.
    4) Эстетика. Код, работающий с датасетами, очень грустный и не особо красивый. Протаскивать датасет через слой бизнес-логики до UI и там делать databind или добавлять новую запись в базу при помощи датасета - для меня это сродни использованию базы данных в UI.
    5) Другие недостатки. У датасетов есть целая куча проблем, связанных с сериализацией, веб-сервисами и т.д. В больших приложениях не всегда можно сказать наверняка, будешь ты их использовать или нет через год. Поэтому лучше не рисковать.
    6) Скорость разработки. Типизированные датасеты здесь рулят, однако с появлением ORM они потеряли и это преимущество. Поэтому я и говорил, что L2S - это хорошая альтернатива.

    Вкратце где-то так. В принципе, можете почитать очень взвешенную статью. Или еще вот эту.

    По поводу производительности датасетов vs. L2S. "Куда как быстрее" - это сколько? В моих тестах даже на сложных запросах L2S проигрывал не более чем в 2 раза датаридерам. Датасеты тоже медленнее работают, раза в полтора. Да и потом, понятное дело, что чистый запрос, который вернет немного данных, в базе выполнится быстрее. Но никто же не мешает написать чистый запрос и в L2S - будет так же быстро.

    ReplyDelete
  4. а я рад, что L2S помирает. Ну не правильно делать два разных ORM!

    Совсем в идеале, было бы неплохо, если бы MS сделал две вещи

    * Облегченный режим работы в EF
    * Переходники интерфейсов L2S в EF, для безболезненного перехода

    ReplyDelete
  5. Юра, если бы MS сделал две описанные тобой вещи, то я согласен - L2S был бы уже не нужен. Но, по всей видимости, первый твой пункт будет реализован не раньше .NET 5.0 (или какая там будет следующая после 4.0 версия), а то и того позже - не до того сейчас ADO.NET team. Что же до второго пункта - то встречаем: LINQ to SQL to Entity Framework conversion template. Это, конечно, еще не автоматический перевод, но уже хотоь что-то :)

    ReplyDelete