TK>И какой у EF6+ уровень поддержки? Проект на codeplex как открыли так и закрыть можно.
Если у тебя есть подписка MSDN и срочный case то им можно возпользоваться и зпэскалэйтить в MS, и при надобности фикс сделают только для тебя лично...
Здравствуйте, Tom, Вы писали:
TK>>И какой у EF6+ уровень поддержки? Проект на codeplex как открыли так и закрыть можно. Tom>Если у тебя есть подписка MSDN и срочный case то им можно возпользоваться и зпэскалэйтить в MS, и при надобности фикс сделают только для тебя лично...
Подписка на MSDN и фикс какого-то там проекта на codeplex который даже не часть .net framework? Может еще и для ночных билдов? Я умоляю...
Решить проблему с авторами linq2db будет сильно проще (как и включить фикс в основную ветку)...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
TK>Подписка на MSDN и фикс какого-то там проекта на codeplex который даже не часть .net framework? Может еще и для ночных билдов? Я умоляю... TK>Решить проблему с авторами linq2db будет сильно проще (как и включить фикс в основную ветку)...
Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF.
Соответственно если мы инвестируем свои деньги в использованием EF мы имеем хорошую гарантию что проект не свернут завтра по какой либо причине.
Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта.
Не дай бог чего с кем случиться — что будет с проектом...
И даже если я лично верю в то что библиотека хорошая то буз большой комьюнити и хорошей поддержки убедить начальство её использовать для нашего проекта невозможно.
Для нас в идеале было бы если бы за проектом стояла бы какая то официальная компания с которой можно было бы заключить офиц. договор и даже заплатить за проект и его поддержку бабло.
Здравствуйте, Tom, Вы писали:
Tom>Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF.
Эта компания закрывает разработку одной технологии за другой с удивительной последовательностью. Сначала прекратилась разработка Linq2SQL, теперь прекращается работа над текущей версией EF. Что они породят на этот раз и сколько это продержится можно только гадать. Тем не менее, компания ведь большая и ей можно верить, ага
Tom>Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта.
Понятное дело. Библитека живёт и развивается уже почти 12 лет без всяких гарантий. Какие тут могут быть гарантии?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF. Tom>Соответственно если мы инвестируем свои деньги в использованием EF мы имеем хорошую гарантию что проект не свернут завтра по какой либо причине. Tom>Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта.
Ню-ню, у меня сейчас 2 направления бизнеса склеивают ласты по причине хорошей поддержке технологии Сильверлайт большой компанией.
И это при том, что Микрософт остается самым вменяемым партнером из всех больших корпораций.
Интересно. Не знал про эту фичу SQL.
А как "навесить хинты" через EF?
G>То есть способ не писать left join руками в Linq. G>Так вот в EF появляется дополнительно вычисляемое поле, по которому потом идет сортировка.
А если left join написан руками, то проблем нет? То есть, всё решение заключается в избегании такого неявного JOIN, или там ещё что-то нужно?
AK>>А какие именно возможности SQL нельзя использовать через EF? G>Например в linq нельзя написать MERGE оператор, использовать output выражения, табличные параметры для функций, FullTextSearch, ranking функции pivot\untivot и много чего еще. Большую часть можно обойти изобретением своих функий, но иногда проще тупо SQL написать.
А есть где-нибудь вот эта информация в сводном виде? Или какие-то исходные данные, из которых можно вывести таблицу — какие возможности SQL поддерживаются в EF, а какие не поддерживаются? У нас многое из перечисленного активно используется — и ranking-функции, и pivot, и merge, и табличные параметры. Мне надо бы рассказать команде про эти вещи и про обходные пути до миграции на EF. Да и самому нужно оценить целесообразность полной миграции — данных у нас очень уж много, некоторые операции по обработке данных длятся по нескольку часов. А такие вещи как MERGE, улучшают производительность (1 операция ввода/вывода вместо двух на SELECT + INSERT/UPDATE), так что часть обработки данных придётся оставить в хранимых процедурах до лучших времён.
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, gandjustas, Вы писали:
G>>>>1) нельзя навесить хинты. Это вообще-то не правда, но люди упорно повторяют эту глупость. AK>>>А "хинт" это что? G>>http://msdn.microsoft.com/en-us/library/ms187713.aspx
AK>Интересно. Не знал про эту фичу SQL. AK>А как "навесить хинты" через EF?
Через EF никак, а создать plan guide на сервере — легко.
G>>То есть способ не писать left join руками в Linq. G>>Так вот в EF появляется дополнительно вычисляемое поле, по которому потом идет сортировка.
AK>А если left join написан руками, то проблем нет? То есть, всё решение заключается в избегании такого неявного JOIN, или там ещё что-то нужно?
Да. Одно исключение — неявный джоин нужен когда надо чтобы ChangeTracking работал.
AK>>>А какие именно возможности SQL нельзя использовать через EF? G>>Например в linq нельзя написать MERGE оператор, использовать output выражения, табличные параметры для функций, FullTextSearch, ranking функции pivot\untivot и много чего еще. Большую часть можно обойти изобретением своих функий, но иногда проще тупо SQL написать.
AK>А есть где-нибудь вот эта информация в сводном виде? Или какие-то исходные данные, из которых можно вывести таблицу — какие возможности SQL поддерживаются в EF, а какие не поддерживаются? У нас многое из перечисленного активно используется — и ranking-функции, и pivot, и merge, и табличные параметры. Мне надо бы рассказать команде про эти вещи и про обходные пути до миграции на EF. Да и самому нужно оценить целесообразность полной миграции — данных у нас очень уж много, некоторые операции по обработке данных длятся по нескольку часов. А такие вещи как MERGE, улучшают производительность (1 операция ввода/вывода вместо двух на SELECT + INSERT/UPDATE), так что часть обработки данных придётся оставить в хранимых процедурах до лучших времён.
Многие вещи можно завернуть во view\inline-функции на сервере. Тут надо смотреть что конкретно используется и как мигрировать. Я бы предложил Linq2DB использовать.
Для начала все равно надо обычные SqlCommand+ручной мэппинг переписать на вызовы ef\linq2db, потом заменить текстовые запросы на IQueryable по возможности, потом выстаскивать проекции и предикаты как можно выше по стеку вызовов. Там где не получится IQueryable, можно оставить как есть.
Здравствуйте, Tom, Вы писали:
TK>>Подписка на MSDN и фикс какого-то там проекта на codeplex который даже не часть .net framework? Может еще и для ночных билдов? Я умоляю... TK>>Решить проблему с авторами linq2db будет сильно проще (как и включить фикс в основную ветку)... Tom>Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF. Tom>Соответственно если мы инвестируем свои деньги в использованием EF мы имеем хорошую гарантию что проект не свернут завтра по какой либо причине.
Практика показывает, что никакой гарантии нет. Передавайте привет силверлайту
Tom>Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта. Tom>Не дай бог чего с кем случиться — что будет с проектом...
Так надо брать не только бинарники но и исходники — один разработчик шибко много не напишет.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IB, Вы писали:
AK>> Переход на EF я рассматриваю как шанс избавиться от хранимых процедур вообще. IB>В принципе это вариант, но не надо использовать EF для этого, посмотрите на другие альтернативы.
У нас для использования любой сторонней библиотеки нужно получать благословение от начальства, так что пока пробую оценить целесообразность миграции именно на EF, так как он уже есть в списке доступных библиотек. Если минусов наберётся слишком уж много, то буду думать.
IB>Основная слабая сторона EF в том, что он насчитывает историю более десяти лет и все это время разработка этого инструмента базировалась на ошибочных представлениях об ORM. Последние несколько лет, они пытались исправить ситуацию, но хвосты торчат до сих пор и мешаются под ногами на каждом шагу. Все остальные частности — лишь следствие, но по факту получился редкостный уродец.
Меня конкретика интересует. Но немного конкретики я уже набрал — косяки при неявном использовании left join (но если с явным left join всё нормально, то это можно отнести к known bug и избегать неявных join'ов), отсутствие доступа к таким возможностям SQL как MERGE, pivot и т.п.
Да, это как-то не комильфо.
Там написано, что совместимость работы через DbContext сильно ломать не будут и миграция должна быть несложной, так что грядущее переписывание EF с нуля меня не сильно пугает -- сейчас есть EF6, который в общем и целом не так уж плох, а через пару лет появится EF7, который будет вообще прекрасен и можно будет на него мигрировать. Но вот из интересного — почитал я там про причины переписывания. Одна из причин там — поддержка SQLite, я так понимаю, SQLite обещается только в EF7? А сейчас SQLite не поддерживается чтоль? А то я планировал использовать SQLite для запуска юнит-тестов в памяти..
Здравствуйте, Sharov, Вы писали:
AK>> С тем, чтобы сначала использовать его для вызова имеющихся хранимых процедур и постепенно, по мере доработки кода, переписывать хранимые процедуры на LINQ-запросы. Ну это чтобы не ломать то, что есть и не тратить полгода на переписывание с нуля. S>Зачем,
Ну хотя бы потому, что если иметь всю бизнес-логику на стороне C#, то C#-разработчикам проще эту логику читать и отлаживать -- всё перед глазами, прямо в Visual Studio.
S>если вы тут в производительности потеряете? Кэширование плана, если это огромный запрос, то экономика трафика и т.д и т.п.
У нас мало запросов, но выполняются они очень долго. Передача огромного запроса — это несколько килобайт SQL-кода, это дело нескольких секунд. Выполняется же каждый запрос по несколько минут.
TK>Так надо брать не только бинарники но и исходники — один разработчик шибко много не напишет.
Если брать исходники, это значит в них разбираться. А если разбираться, то следующий вопрос, как с ними жить. Можно жить вместе с библиотекой и слать патчи с просьбой закомитить в основную ветку. А можно отделиться и фактически писать свой linq provider, поглядывая в имеющуюся реализацию. При этом в своих исходниках можно кое-что упростить, выкинув неактуальные вещи: поддержку десятков СУБД и т.д., дописать нужные твоему проекту вещи. Но в этом варианте ты не можешь автоматом получить того развития, которое идет в исходной библиотеке. Таким образом, “взять исходники” постепенно и незаметно выльется в ощутимые затраты времени разработчиков.
Когда берешь что-то массовое типа EF, то есть поддержка со стороны поисковой строки в google.com. Но есть проблемы с архитектурной кривизной EF.
Для себя я вижу выход в том, чтобы не уходить далеко от чистого ADO.NET. Не должно быть много исходников в библиотеке, которая обеспечивает доступ к СУБД.
Re[21]: Почему вы НЕ используете Entity Framework?
Здравствуйте, Alexander Polyakov, Вы писали:
AP>А вас не пугает в EF7 вот это:
Да пофиг. Как напишут — посмотрим что получится, а для текущих задач мне вполне хватает linq2SQL и linq2db.
Здравствуйте, Alexander Polyakov, Вы писали:
AK>>... мне уже приходилось писать подобие юнит-тестов для EF, где использовалась временная база данных на реальном SQL-сервере. Это работает, но медленно. AP>Насколько медленно, в миллисекундах сколько и на что тратится?
Сейчас я работаю над другим проектом, так что посмотреть уже не могу. Но больше всего времени там уходило на создание временной базы данных и на очистку данных между тестами (DELETE/TRUNCATE). Создание временных таблиц и ещё что-то в этом духе.
С уважением, Artem Korneev.
Re[2]: Потому что у нас и так все хорошо работает :)
Здравствуйте, rm822, Вы писали:
AK>>трудности написания юнит-тестов для хранимых процедур R>можно подумать есть принципиальная разница между тестированием ХП и кода на шарпе
Есть практическая разница. Отлаживать и покрывать юниттестами C# код сильно проще. По крайней мере, нашей команде.
AK>>Сейчас на legacy-проекте есть полтора разработчика, которые хорошо ориентируются в имеющихся SQL-процедурах R>Прекрасная новость, как мне кажется
Что именно? То, что на проекте всего полтора разработчика, которые могут за приемлемое время разобраться в имеющемся SQL-коде?
Немалая часть багов за последнее время всплывала именно в SQL-коде, который на данный момент не покрыт юнит-тестами вообще никак.
AK>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте? R>Минусы в использовании практически любой подобной хрени всегда одни и те же R>- слой хранимок/вьюх это слой абстракции отделяющий физическую структуру данных от интерфейса. При наличии dev-DBA он необходим
У нас это не слой абстракции, у нас туда уехала уже куча бизнес-логики. dev-DBA у нас нет.
R>- реализация BL вне хранимок создает лишний трафик, из-за передачи данных из сервера БД
Не создаёт. ORM работает с данными через динамически генерируемые SQL-запросы.
R>- реализация BL вне хранимок часто категорически неприемлема, если сервер БД _может_ находиться далеко (например издыхание сервера БД в основном ДЦ, и автоматический фэйловер к резервному, до которого пинг 70мс, азуры, амазоны, просто фиговый коннект в корпоративном интранете)
Хранимки от не-хранимок отличаются только передачей текста запроса -- в случае ORM запрос генерируется динамически и отправляется на сервер, где его ещё нужно распарсить и запустить. При использовании хранимых процедур -- текст уже там.
В моих сценариях эта разница несущественна, т.к. время отправки запроса в любом случае пренебрежимо мало по сравнению со временем выполнения этого запроса -- секунды против минут или даже десятков минут.
Ещё один минус Entity Framework — то, что он не умеет использовать некоторые возможности SQL -- merge, pivot и т.д. Вот это для нас уже более существенно. Будем думать.
С уважением, Artem Korneev.
Re[21]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>1) Я не утверждал что в EF "SQL генерится самый лучший на свете", я говорил что в совокупности покачто нет ничего лучше.
Вот тут самое время опять вспомнить про женскую логику — можешь объяснить разницу между "самый лучший на свете" и "в совокупности нет ничего лучше"?
G>2) Ты показал ровно один баг, который легко обходится. На "косяк в архитектуре" один баг не тянет.
Я тебе этот баг не просто показал. Я тебе его предсказал основываясь на знании архитектуры EF, таким образом — этот баг лишь следствие особенностей архитектуры, а не просто ошибка которую не заметили.
G>С чего ты взял что он системный? Это лишь твои домыслы.
Как можно заметить — мои домыслы часто оказываются очень верными. Я тебе даже объяснил на чем эти домыслы основаны Однако я полностью признаю за тобой право продолжать считать это лишь домыслами. ))
G>Я слишком хорошо знаю как работает маркетинг МС, чтобы не верить ни одному пресс-релизу.
Тут видишь ли какое дело. Если маркетинг МС говорит, что за какой-то технологией будущее, то действительно, фиг его знает как оно на самом деле... Однако если он говорит, что на какую-то технологию компания кладет болт — то еще не было примеров того, чтобы эту технологию потом продолжали развивать.
Так что если ты действительно хорошо знаешь маркетинг МС, то с EF ситуация намного хуже того, что написано в этом пресс-релизе. На очень много хуже.
G>Поэтому я читаю код вместо маркетингового буллшита.
Похоже, что и код читать у меня пока получается лучше чем у тебя
Здравствуйте, Artem Korneev, Вы писали:
AK>У нас для использования любой сторонней библиотеки нужно получать благословение от начальства, так что пока пробую оценить целесообразность миграции именно на EF, так как он уже есть в списке доступных библиотек. Если минусов наберётся слишком уж много, то буду думать.
Тогда лучше брать linq2SQL — с ним точно ничего не будет, так как он часть фреймворка. Его достоинство в том, что он простой как рельс, его функциональности хватает процентов на 90 задач и на нем просто невозможно написать неправильно. Чуть больше ручной работы, зато все происходит явно и прозрачно, и очень низкий порог вхождения.
Потом можно будет довольно просто перейти на любой linq ORM, если вдруг его функционала окажется недостаточно.
AK>Меня конкретика интересует. Но немного конкретики я уже набрал — косяки при неявном использовании left join (но если с явным left join всё нормально, то это можно отнести к known bug и избегать неявных join'ов),
Так как проблема системная, то прежде чем вы сможете действительно уверенно писать с использованием EF избегая всех скользких моментов — придется вложить довольно много усилий в освоение этого продукта. А потом эти знания окажутся бесполезными, как только они его все-таки перепишут.
Есть конечно вариант забить на все это и писать лишь бы работало, дождаться EF7 и оптимизировать уже под него, но это уж вам решать.
AK>Одна из причин там — поддержка SQLite, я так понимаю, SQLite обещается только в EF7? А сейчас SQLite не поддерживается чтоль?
Поддерживается, но не очень стабильно
However, that I have decided that SQLite is not a good fit for the Entity Framework, as too many critical functions are missing. I switched over to SQL Server Compact Edition, which I installed via NuGet. A simple tweak to my Connection String and I was running with the full power of Entity Framework. It took less than a minute, compared to the multi-hour slog that was SQLite. I'd recommend switching databases if possible, System.Data.SQLite just isn't ready for the Entity Framework.
Мы уже победили, просто это еще не так заметно...
Re[22]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>1) Я не утверждал что в EF "SQL генерится самый лучший на свете", я говорил что в совокупности покачто нет ничего лучше. IB>Вот тут самое время опять вспомнить про женскую логику — можешь объяснить разницу между "самый лучший на свете" и "в совокупности нет ничего лучше"?
В совокупности нет лучше не говорит о том, что ef будет лучше в каждом конкретном случае.
Например для миграции legacy кода, работающего через SqlCommand гораздо лучше подойдет Linq2db
G>>2) Ты показал ровно один баг, который легко обходится. На "косяк в архитектуре" один баг не тянет. IB>Я тебе этот баг не просто показал. Я тебе его предсказал основываясь на знании архитектуры EF, таким образом — этот баг лишь следствие особенностей архитектуры, а не просто ошибка которую не заметили.
Все равно это один баг
G>>Я слишком хорошо знаю как работает маркетинг МС, чтобы не верить ни одному пресс-релизу. IB>Тут видишь ли какое дело. Если маркетинг МС говорит, что за какой-то технологией будущее, то действительно, фиг его знает как оно на самом деле... Однако если он говорит, что на какую-то технологию компания кладет болт — то еще не было примеров того, чтобы эту технологию потом продолжали развивать. IB>Так что если ты действительно хорошо знаешь маркетинг МС, то с EF ситуация намного хуже того, что написано в этом пресс-релизе. На очень много хуже.
Включай голову:
1) За последние 3 года ситуация с EF не менялась. В версии 5 написали обертку вокруг ObjectContext, в версии 6 её значительно переписали, почему нельзя было также сделать в версии 7?
2) Совершенно случайно планы по переписыванию EF совпали с изобретением KRuntime и появлением SQLite на windows 8. И совершенно случайно EF на них не заработал.
3) Также случайно переписывание EF совпало с идеей продвижения W8 в enterprise и развитием и развитием ASP.NET в сторону универсальности (напомню что EF — часть asp.net)
Получается что переписывание вызвано вовсе не проблемами в EF (они за три года не поменялись), а только необходимостью работы под новыми платформами и новыми базами).
Также многократно замечено что маркетинг МС готов называть черное белым, а белое черным для реализации стратегии продвижения. Достаточно вспомнить что каждая вторая версия windows позиционируется как нечто революционное, написанное с нуля, хотя по факту является доработкой предыдущей версии до ума.
А лично у меня есть пример потрясающего маркетинга SharePoint, который уже два года рассказывает что server-side код это зло и срочно надо всем в облака, вот только облака закрывают от силы половину потребностей.
Вообще объявить предыдущую версию говном — в порядке вещей для MS. Почему-то это считается индульгенцией для любого, даже самого шандарахнутого плана. Причем не зависимо от реального качества предыдущей версии.
Здравствуйте, TK, Вы писали:
TK>Практика показывает, что никакой гарантии нет. Передавайте привет силверлайту
Вот-вот. Зубоскалить можно много, но вот умерший и закопаный Silverlight мейтейнится до сих пор. И аргументы, приведённые Tom-ом таки да, зачастую оказываются решающими: в подобном разговоре(внутри компании) мне вот прямо задали вопрос, что произойдёт с l2db если завтра на главного разработчика упадёт кирпич на улице, и я как-то затруднился описать перспективы. В отличии от аналогичной ситуации с l2e.
Собственно после этого тема "а давайте запилим на l2db" больше не поднималась.
Здравствуйте, IB, Вы писали:
AK>>Одна из причин там — поддержка SQLite, я так понимаю, SQLite обещается только в EF7? А сейчас SQLite не поддерживается чтоль? IB>Поддерживается, но не очень стабильно
Интересно, какие там могут быть сложности?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Потому что у нас и так все хорошо работает :)
R>>можно подумать есть принципиальная разница между тестированием ХП и кода на шарпе AK>Есть практическая разница. Отлаживать и покрывать юниттестами C# код сильно проще. По крайней мере, нашей команде.
А что именно у вас вызывает сложности (если отбросить "непривычно")?
AK>Что именно? То, что на проекте всего полтора разработчика, которые могут за приемлемое время разобраться в имеющемся SQL-коде?
Что 1.5 разработчика есть, это намного лучше чем 0
R>>- реализация BL вне хранимок создает лишний трафик, из-за передачи данных из сервера БД AK>Не создаёт. ORM работает с данными через динамически генерируемые SQL-запросы.
Вообще-то создает, и природа этого — неполная поддержка идиом SQLя.
Этот псевдо-код вы перепишете на выборку данных не во временную таблицу #t, а в приложение. AFAIK нет ведь поддержки временных таблиц в EF?
select ... into #t from ...
if exists(select ... from #t where ...)
exec proc1
if exists(select ... from #t where ...)
exec proc2
...
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
