Ок, допустим я среднестатистический senior, для которого технические аргументы при выборе инструмента работы с базой имеют значение. Я открываю документацию linq2db и мне все нравится — гибкость, расширяемость; то, что решается конкретная задача сделать статически типизированный sql, который ещё и composable и прочие хорошие слова; а нерешимая на практике задача, например, по достижению persistence ignorance, не решается, что даёт основание подозревать, что авторы что-то понимают в жизни.
Я делаю POC по переносу самых заковыристых кусков проекта (где запрос собирался путём склеивания строк) на linq2db и меня все устраиваетустраивает:
how to teacher linq и трюк с Compile() позволили сделать то, что мне нужно.
Далее мне нужно продать это решение и возникают такие вопросы: а насколько linq2db зрелый продукт, много ли в нём багов, поддерживается ли он какой-нибудь большой компанией, на сколько он распространен и т.п.
Если использовать в проекте какой-нибудь Dapper, то ответы сразу находятся: Dapper все знают, он разработан и используется в stackoverflow, он позиционируется как легковесная альтернатива ORM (первой версии LinqToSql на момент разработки), он на столько примитивен, что баги там врятли есть.
Ответы по Linq2Db: он достаточно наворочен и универсален, так что баги там наверняка есть; с распространённость не очень, судя по документации; в последнее время поддерживается, в основном, парочкой энтузиастов (справедливости ради, очень крутых разработчиков): sdanyliv и MaceWindu; IT временно самоустранился.
Что, как мне представляется, добавило бы аргументов в пользу выбора linq2db:
1. Success stories, список компаний и продуктов, использующих linq2db. Подозреваю, что он используется много кем, не только тремя "Notable open-source users" из документации.
2. Наличие платной поддержки очень бы помогло.
Здравствуйте, artelk, Вы писали:
A>Ок, допустим я среднестатистический senior, для которого технические аргументы при выборе инструмента работы с базой имеют значение. Я открываю документацию linq2db и мне все нравится — гибкость, расширяемость; то, что решается конкретная задача сделать статически типизированный sql, который ещё и composable и прочие хорошие слова; а нерешимая на практике задача, например, по достижению persistence ignorance, не решается, что даёт основание подозревать, что авторы что-то понимают в жизни.
A>Я делаю POC по переносу самых заковыристых кусков проекта (где запрос собирался путём склеивания строк) на linq2db и меня все устраиваетустраивает: how to teacher linq и трюк с Compile() позволили сделать то, что мне нужно.
A>Далее мне нужно продать это решение и возникают такие вопросы: а насколько linq2db зрелый продукт, много ли в нём багов, поддерживается ли он какой-нибудь большой компанией, на сколько он распространен и т.п.
A>Если использовать в проекте какой-нибудь Dapper, то ответы сразу находятся: Dapper все знают, он разработан и используется в stackoverflow, он позиционируется как легковесная альтернатива ORM (первой версии LinqToSql на момент разработки), он на столько примитивен, что баги там врятли есть.
A>Ответы по Linq2Db: он достаточно наворочен и универсален, так что баги там наверняка есть; с распространённость не очень, судя по документации; в последнее время поддерживается, в основном, парочкой энтузиастов (справедливости ради, очень крутых разработчиков): sdanyliv и MaceWindu; IT временно самоустранился.
A>Что, как мне представляется, добавило бы аргументов в пользу выбора linq2db:
A>1. Success stories, список компаний и продуктов, использующих linq2db. Подозреваю, что он используется много кем, не только тремя "Notable open-source users" из документации.
A>2. Наличие платной поддержки очень бы помогло.
Ну как бы даже и не поспоришь, но ситуация такая, что действительно сейчас активных два разработчика (есть люди, активные набегами, но не приживаются на долго что-то), которые занимаются всем этим в свободное время, соответственно:
— все сразу делать не получается, приходится расставлять приоритеты и PR там не на первом месте — и без него задач хватает
— соответственно и о какой-то платной поддержке речи идти не может — брать дополнительную ответственность некуда
Я бы сказал что единственная проблема у нас — это нехватка рук. Задач на любой вкус найти не проблема (их есть у нас):
— разработка
— поддержка
— документация
— pr
Здравствуйте, artelk, Вы писали:
A>Ок, допустим я среднестатистический senior, для которого технические аргументы при выборе инструмента работы с базой имеют значение. Я открываю документацию linq2db и мне все нравится — гибкость, расширяемость; то, что решается конкретная задача сделать статически типизированный sql, который ещё и composable и прочие хорошие слова; а нерешимая на практике задача, например, по достижению persistence ignorance, не решается, что даёт основание подозревать, что авторы что-то понимают в жизни.
A>Я делаю POC по переносу самых заковыристых кусков проекта (где запрос собирался путём склеивания строк) на linq2db и меня все устраиваетустраивает: how to teacher linq и трюк с Compile() позволили сделать то, что мне нужно.
A>Далее мне нужно продать это решение и возникают такие вопросы: а насколько linq2db зрелый продукт, много ли в нём багов, поддерживается ли он какой-нибудь большой компанией, на сколько он распространен и т.п.
Как бы 10 лет продукту, тестов столько что студия не выдерживает. Каждый фикс подкрепляется регресионным тестом.
A>Если использовать в проекте какой-нибудь Dapper, то ответы сразу находятся: Dapper все знают, он разработан и используется в stackoverflow, он позиционируется как легковесная альтернатива ORM (первой версии LinqToSql на момент разработки), он на столько примитивен, что баги там врятли есть.
Конечно на баг наткнуться можно, но в 99% случааев есть воркараунд, пока не профиксаем.
A>Ответы по Linq2Db: он достаточно наворочен и универсален, так что баги там наверняка есть; с распространённость не очень, судя по документации; в последнее время поддерживается, в основном, парочкой энтузиастов (справедливости ради, очень крутых разработчиков): sdanyliv и MaceWindu; IT временно самоустранился.
Игорь забегает
A>Что, как мне представляется, добавило бы аргументов в пользу выбора linq2db:
A>1. Success stories, список компаний и продуктов, использующих linq2db. Подозреваю, что он используется много кем, не только тремя "Notable open-source users" из документации.
Даже не знаю. Бывает что к нам приходит заказчик и просит писать на linq2db
A>2. Наличие платной поддержки очень бы помогло.
Вот не задумывался еще как бы это монетизировать. Но да, если есть вразумительная причина и что что-то надо сделать, можно подумать и о оплате.
