Здравствуйте, VladD2, Вы писали:
VD>Сейчас для этого используют обычные объекты и биндинг в WPF. А для доступа к данным разные надстройки над LINQ. Мы вот заюзали LINQ2DB написанный одним из основателей этого сайта IT. Еще есть убогенький Entity Framework.
2 Коваленко Дмитрий: Что смешного в моих словах?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Здравствуйте, VladD2, Вы писали: VD>>Сейчас для этого используют обычные объекты и биндинг в WPF. А для доступа к данным разные надстройки над LINQ. Мы вот заюзали LINQ2DB написанный одним из основателей этого сайта IT. Еще есть убогенький Entity Framework. VD>2 Коваленко Дмитрий: Что смешного в моих словах?
Да так, навеяло. Ничего личного.
Я вот что хотел бы спросить здесь.
У MS вроде была Linq для SQL. У меня даже толстая книжка есть про этот Linq.
Но потом они её закопали? Предложив EF6?
А теперь снова откопали в своем EFCore?
Так?
Я вообще ничего не писал под эти вещи не писал.
Хотя под EFCore (повторно) пытаюсь написать провайдер.
Мда
Сначало вроде неплохо пошло. Но потом уколебался спотыкаться об их код. И их похоже задрал
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>У MS вроде была Linq для SQL. У меня даже толстая книжка есть про этот Linq. КД>Но потом они её закопали? Предложив EF6?
У MS была реализация для MS SQL Server, но MS на нее забил. Сейчас MS предлагает только EF. Они его конечно развивают, но и по скорости и по удобству LINQ2DB лучше.
КД>А теперь снова откопали в своем EFCore?
EF — это универсальной фрэймворк не привязанный к Сиквелу. Плюс там море наворотов. Связи с провадером для Сивела у него нет. EF Core — это развитие EF из фрэймворка.
КД>Хотя под EFCore (повторно) пытаюсь написать провайдер.
А зачем провайдер то? Провайдер нужен если есть свой источник данных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>У MS была реализация для MS SQL Server, но MS на нее забил. Сейчас MS предлагает только EF. Они его конечно развивают, но и по скорости и по удобству LINQ2DB лучше.
Здравствуйте, VladD2, Вы писали:
VD>EF — это универсальной фрэймворк не привязанный к Сиквелу. Плюс там море наворотов. Связи с провадером для Сивела у него нет. EF Core — это развитие EF из фрэймворка.
Сиквелу — это SQL? А не MSSQL?
КД>>Хотя под EFCore (повторно) пытаюсь написать провайдер.
VD>А зачем провайдер то? Провайдер нужен если есть свой источник данных.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Сиквелу — это SQL? А не MSSQL?
Нет. Я именно про MSSQL говорил. EF его поддерживает тоже, но и другие серверы тоже. А то был специализированный провайдер.
КД>У меня есть свой ADO.NET провайдер. Я хочу натянуть на него EFCore. Пока еще хочу...
А. Ясно. Ну, это похвальное начинание.
КД>LINQ2DB я как-то натягивал. Почти натянул. Но в конце все пошло не так.
Ну, так обратился бы к автору. Он очень отзывчев. Да и другие могли бы помочь.
КД>... идеи там наверное хорошие. А вот реализация
Да, ладно! Не наговаривай. Если бы там все было плохо, столько народа его не использовало бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Сиквелу — это SQL? А не MSSQL?
VD>Нет. Я именно про MSSQL говорил. EF его поддерживает тоже, но и другие серверы тоже. А то был специализированный провайдер.
И это правильно, наверное. А то получаются вещи, гвоздями приколоченные к полу.
КД>>LINQ2DB я как-то натягивал. Почти натянул. Но в конце все пошло не так.
VD>Ну, так обратился бы к автору. Он очень отзывчев. Да и другие могли бы помочь.
Я общался с ними
КД>>... идеи там наверное хорошие. А вот реализация
VD>Да, ладно! Не наговаривай. Если бы там все было плохо, столько народа его не использовало бы.
Я говорил про эти вещи (EFCore, Linq2Db) в целом.
И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Не оверквоть, плиз.
КД>И это правильно, наверное. А то получаются вещи, гвоздями приколоченные к полу.
Что же правильного в не универсальных решениях? Так путем смены конфига ты можешь поменять используемый сервер. Скажем в базовом варианте ты используешь бесплатный Sqlight, а в расширеном MS SQL Server или Oracle. Конечно, какие-то ресурсы при этом придется потратить на обеспечение совместимости, но код будет единым. Не придется писать отдельные решения для поддержки всех видов сервером.
КД>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.
Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
КД>>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.
VD>Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.
Да, Copy&Paste — сильная вещь.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Обратите внимание, что сама WinForms испытала некоторые проблемы при пересадке со старой платформы .NET Framework только для Windows на кросс-платформенную схему .NET Core с открытым исходным кодом (теперь она является частью .NET 5).
Команда разработчиков Microsoft в конце прошлого года объяснила "огромную техническую проблему", с которой она столкнулась при создании конструктора WinForms на .NET Core.
"Для разработчиков .NET Core Windows Forms Designer (когда мы выпустим версию GA) будет выглядеть и чувствовать себя так же, как и .NET Framework Windows Forms Designer", — сказала Оля Гавриш, менеджер программ .NET, в октябре 2019 года. "Но для нас это огромная техническая проблема, чтобы привести дизайнера к .NET Core, потому что это требует поверхности разработки, которая размещает живую форму .NET Core, чтобы работать вне процесса Visual Studio. Это означает, что нам нужно заново спроектировать способ, которым дизайнерская поверхность "взаимодействует" с Visual Studio."
Растущая пандемия COVID-19 также вызвала некоторые проблемы в достижении первоначальных целей .NET 5, так что другие функциональные возможности планировалось включить в Nov. 10 дебют .NET 5 был отложен до .NET 6, выпуска долгосрочной поддержки (LTS), запланированного на ноябрь 2021 года.
и солнце б утром не вставало, когда бы не было меня
я думаю, они банально недооценили размер проблемы, написать новый дизайнер для винформс, да еще с роутингом между процессами. Т.е. когда они только первый раз нам рассказывали, что они планируют, в 19 году, это уже было очевидно. Но прогресс неплохой, могло быть хуже.
Здравствуйте, notacat, Вы писали:
N>я думаю, они банально недооценили размер проблемы, написать новый дизайнер для винформс, да еще с роутингом между процессами. Т.е. когда они только первый раз нам рассказывали, что они планируют, в 19 году, это уже было очевидно. Но прогресс неплохой, могло быть хуже.
Что такое "роутинг между процессами" в контексте дизайнера?
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, VladD2, Вы писали:
КД>>>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.
VD>>Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.
КД>Да, Copy&Paste — сильная вещь.
Ты и нас достал и EF Core команду. Вместо того чтобы писать провайдер, начал учить как надо писать код. И надо было все бросить и написать как надо прям на завтра.
Сначала делается дело, потом смотрится что можно улучшить. Бывает что можно дорефакториться и получить проседание в скорости или того хуже в памяти на ровном месте. И потом уже ты смотришь на предыдущее решение внимательней.
Копипаста в провайдерах присутствует минимально и постепенно устраняется, опять же прогнав через BenchmarkDotNet.
Здравствуйте, Sharov, Вы писали: S>Что такое "роутинг между процессами" в контексте дизайнера?
Форма живёт в одном процессе, а бэкенд компилятора (roslyn et al) — в другом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
N>>я думаю, они банально недооценили размер проблемы, написать новый дизайнер для винформс, да еще с роутингом между процессами. Т.е. когда они только первый раз нам рассказывали, что они планируют, в 19 году, это уже было очевидно. Но прогресс неплохой, могло быть хуже.
S>Что такое "роутинг между процессами" в контексте дизайнера?
Поверхность дизайнера вместе с содержимым — один процесс в .Net 5, студия и проперти грид — другой процесс в .Net 4.(7 или 8, не помню), чтобы показать что-то в проперти гриде, сериализовать, а изменения применить к дизайнеру — каждый раз надо как-то пробросить все типы туда-обратно. Может роутинг не то слово, давно не читала русскоязычной документации
Здравствуйте, Danchik, Вы писали:
КД>>Да, Copy&Paste — сильная вещь.
D>Ты и нас достал и EF Core команду. Вместо того чтобы писать провайдер, начал учить как надо писать код. И надо было все бросить и написать как надо прям на завтра.
Ой, ой, ой.
---
Понять и простить (с) Один из разработчиков Firebird. Наверное в 2013-ом году.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Danchik, Вы писали:
КД>>>>И есть большая разница между использовать и писать запчасть. Во втором случае не все так радужно.
VD>>>Ну, так то, что для EF и LINQ2DB написано море провайдеров говорит о том, что авторы уделили серьезное внимание созданию инфраструктуры провайдеров.
КД>>Да, Copy&Paste — сильная вещь.
D>Ты и нас достал и EF Core команду. Вместо того чтобы писать провайдер, начал учить как надо писать код.
Здравствуйте, IT, Вы писали: DDD>>В общем, я закончил свою штуку. Под EF Core. IT>А зачем эта штука нужна, да ещё через OLE DB? Есть же нормальный нативный FB3 провайдер.
Разработчик FBNetProvider про свое поделие. 2013 год.
[1] Let’s face it, the code is crappy. Redesign would be nice. But I
don’t blame anybody, 5-10 years ago it was different story. .NET was
different (a lot) and we had different understanding of how it works
and should work (and how we should design code).
С тех пор там практически ничего не поменялось. С моей точки зрения.
---
Что касается OLE DB (IBProvider).
Меня вообще забавляют такие вопросы.
Сейчас этот слой предоставляет базовые сервисы для взаимодействия с сервером.
Управление ресурсами подключения, всякие парсеры/конверторы/кэши, механику результирующих множеств и так далее и тому подобное.
Ну, в общем, сейчас это самодостаточный клиент к FB, предоставляющий вполне приличный объектный API. Который полностью освобождает верхний уровень от всякой низкоуровневой мути.
По уровню сложности и надежности, скажем так, он выходит за рамки обывательского представления о такого рода компонентах.
Так что эту штуку уже не объехать и не перепрыгнуть.
И я рассмеюсь в лицо тому, кто скажет, что он сможет заместить его функционал
Он по-моему сейчас поддерживает около 20 разных версий FB/IB, два типа ISC API.
А для FB еще до кучи предоставляет заново спроектированный и исправленный сетевой клиент (их родной меня задрал).
Кста, к IBProvider-у еще сервис пула OLEDB подключений прилагается на замену системному (тоже утомил).
Здравствуйте, DDDX, Вы писали:
IT>>А зачем эта штука нужна, да ещё через OLE DB? Есть же нормальный нативный FB3 провайдер. DDD>С тех пор там практически ничего не поменялось. С моей точки зрения.
А как остальной мир живёт в таких невыносимых условиях?
DDD>Что касается OLE DB (IBProvider). DDD>Меня вообще забавляют такие вопросы.
Это да. Меня тоже забавляют такие ответы.
DDD>ADO.NET провайдер (lcpi.data.oledb) — "просто транслятор вызовов" в OLEDB провайдер.
Т.е. линукс похрен. К тому же, чтобы запустить прогу, использующую эту хрень, нужно ставить и настраивать кучу всякого.
DDD>А вообще, в целом, поскольку внизу лежит нормальный провайдер данных, внутри windows-приложения можно чудить не по-детски.
Мне всегда казалось, что задача провайдера данных не "чудить не по-детски", а прилежно передавать SQL от клиента к серверу и полученный результат обратно. Разве не так?
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
