Как дораскалываем до конца года и наконец выспимся может дойдут руки написать статью) Ну а так у всех команд в Иннотех наверное по разному. У нашей все просто, выпиливаем основные домены в отдельные сервисы, приправляем оркестратором, дружим все это по брокеру, поочередно выносим основную функциональность в отдельные сервисы и молимся чтобы сетевые нагрузки не порушили SLA ответов. Ну и попутно заставляем оркестратор раскалывать запросы на куски чтобы часть шла в старый монолит а часть на новые микросервисы и отправляем это дело на продакшн, чтобы выводить в прод и тестировать все это безобразие по отдельности. Затем потихоньку отщипываем функциональность в отдельные сервисы попутно выпиливая их из монолита. Но мы с командой делаем в Иннотех бэк с ml модельками так что у нас домены в принципе не сильно связаны изначально не смотря на монолитную архитектуру. Возможно у команд где есть фронт и сильная связность история будет поинтереснее)
Ну, в 2022 это все ещё используют ребята из stackoverflow которые и являются по совместительству разработчиками Dapper, на котором и держится их система)
Ну и никто не запрещает комбинировать EF или linq2db для простых запросов не требующих высокой скорости и Dapper для мест где работа с БД требует скорости и тонкой оптимизации. Как раз на эту тему у ребят на страничке в github есть бенчмарки https://github.com/DapperLib/Dapper
Ну сами создатели Dapper позиционируют и называют его micro-ORM (Object–relational mapping), так что это не я придумал)
А по поводу использования EF для более сложных сценариев не соглашусь, поскольку есть противоположный пример отказа от тяжеловесной EF. EF тесно имплементирует сущности БД в архитектуру проекта и при увеличивающейся сложности бизнес-процессов внутри вашего проекта дает эффект, что код сервиса начинает сильно завесить от БД и небольшие изменения в бизнес-логике будут всегда вести к изменению схемы БД.
Мы же стараемся придерживаться подхода что БД отвечает только за хранение данных и выбираем структуру, схему и вид БД исходя из данных.
В то время как код приложения написан по DDD и старается моделировать бизнес-процессы такими какие они есть и соответственно классы отражают реальные физические объекты и их свойства, без понимания того как они хранятся в БД.
А Dapper в этой связке как раз и позволяет нам просто наполнить наши классы данными, например у нас есть часть классов которые вообще наполняются из mongo и redis)
P.S. Соглашусь что Dapper подходит не для всех проектов и не является серебрянной пулей, в данной статье просто хотел показать как выглядит код и способ работы с этой библиотекой
Ну в нашей ситуации тяжело вести актуальность БД со всей кодовой базой, поскольку бывают случаи когда одна таблица используется для нескольких микросервисов на readonly и изменение схемы ведет к необходимости изменения всей кодовой базы в разных репах что довольно-таки трудозатратно.
Так же часто возникает необходимость маппить одни и те же данные на различные бизнес сущности и в них названия могут отличаться по смыслу.
Тут все зависит от подхода работы с БД, у нас классы не являются Entity а представляют некую бизнес-часть и слабо связны с БД, при этом один класс может наполняться данными сразу из многих таблиц, либо данные из одной таблицы могут накачиваться в различные классы в процессе жизни приложения.
Поэтому несоответствие названия поля в БД и свойства в классе для нас абсолютно нормальное явление поскольку структура классов не повторяет БД 1 в 1, в тестовых примерах в статье к сожалению не получилось подробно раскрыть эту тему
Действительно так можно сделать, но здесь скорее суть в том что часто в БД и в запросах названия различаются, например в БД поле dt а в коде мы хотим иметь возможность назвать его Date + не хочется чтобы при рефакторинге поломались запросы если например в коде мы захотим переименовать Date в LastDate, поэтому я вижу более безопасным прописывать свойства напрямую через nameof()
Спасибо, за комментарий. Сейчас как раз рассматриваем возможность перехода на linq2db, но пока уперлись в скорость работы, все таки linq2db работает медленнее чем Dapper и сложные запросы писать в SQL синтаксисе как по мне проще, нагляднее, и предсказуемее + Rider позволяет их сразу из кода выполнить и протестить без запуска приложения.
Information
Rating
Does not participate
Location
Тюмень, Тюменская обл. и Ханты-Мансийский АО, Россия
Как дораскалываем до конца года и наконец выспимся может дойдут руки написать статью) Ну а так у всех команд в Иннотех наверное по разному. У нашей все просто, выпиливаем основные домены в отдельные сервисы, приправляем оркестратором, дружим все это по брокеру, поочередно выносим основную функциональность в отдельные сервисы и молимся чтобы сетевые нагрузки не порушили SLA ответов. Ну и попутно заставляем оркестратор раскалывать запросы на куски чтобы часть шла в старый монолит а часть на новые микросервисы и отправляем это дело на продакшн, чтобы выводить в прод и тестировать все это безобразие по отдельности. Затем потихоньку отщипываем функциональность в отдельные сервисы попутно выпиливая их из монолита. Но мы с командой делаем в Иннотех бэк с ml модельками так что у нас домены в принципе не сильно связаны изначально не смотря на монолитную архитектуру. Возможно у команд где есть фронт и сильная связность история будет поинтереснее)
Ну, в 2022 это все ещё используют ребята из stackoverflow которые и являются по совместительству разработчиками Dapper, на котором и держится их система)
Ну и никто не запрещает комбинировать EF или linq2db для простых запросов не требующих высокой скорости и Dapper для мест где работа с БД требует скорости и тонкой оптимизации. Как раз на эту тему у ребят на страничке в github есть бенчмарки https://github.com/DapperLib/Dapper
Ну сами создатели Dapper позиционируют и называют его micro-ORM (Object–relational mapping), так что это не я придумал)
А по поводу использования EF для более сложных сценариев не соглашусь, поскольку есть противоположный пример отказа от тяжеловесной EF.
EF тесно имплементирует сущности БД в архитектуру проекта и при увеличивающейся сложности бизнес-процессов внутри вашего проекта дает эффект, что код сервиса начинает сильно завесить от БД и небольшие изменения в бизнес-логике будут всегда вести к изменению схемы БД.
Мы же стараемся придерживаться подхода что БД отвечает только за хранение данных и выбираем структуру, схему и вид БД исходя из данных.
В то время как код приложения написан по DDD и старается моделировать бизнес-процессы такими какие они есть и соответственно классы отражают реальные физические объекты и их свойства, без понимания того как они хранятся в БД.
А Dapper в этой связке как раз и позволяет нам просто наполнить наши классы данными, например у нас есть часть классов которые вообще наполняются из mongo и redis)
P.S. Соглашусь что Dapper подходит не для всех проектов и не является серебрянной пулей, в данной статье просто хотел показать как выглядит код и способ работы с этой библиотекой
Ну в нашей ситуации тяжело вести актуальность БД со всей кодовой базой, поскольку бывают случаи когда одна таблица используется для нескольких микросервисов на readonly и изменение схемы ведет к необходимости изменения всей кодовой базы в разных репах что довольно-таки трудозатратно.
Так же часто возникает необходимость маппить одни и те же данные на различные бизнес сущности и в них названия могут отличаться по смыслу.
Тут все зависит от подхода работы с БД, у нас классы не являются Entity а представляют некую бизнес-часть и слабо связны с БД, при этом один класс может наполняться данными сразу из многих таблиц, либо данные из одной таблицы могут накачиваться в различные классы в процессе жизни приложения.
Поэтому несоответствие названия поля в БД и свойства в классе для нас абсолютно нормальное явление поскольку структура классов не повторяет БД 1 в 1, в тестовых примерах в статье к сожалению не получилось подробно раскрыть эту тему
Действительно так можно сделать, но здесь скорее суть в том что часто в БД и в запросах названия различаются, например в БД поле dt а в коде мы хотим иметь возможность назвать его Date + не хочется чтобы при рефакторинге поломались запросы если например в коде мы захотим переименовать Date в LastDate, поэтому я вижу более безопасным прописывать свойства напрямую через nameof()
Спасибо, за комментарий. Сейчас как раз рассматриваем возможность перехода на linq2db, но пока уперлись в скорость работы, все таки linq2db работает медленнее чем Dapper и сложные запросы писать в SQL синтаксисе как по мне проще, нагляднее, и предсказуемее + Rider позволяет их сразу из кода выполнить и протестить без запуска приложения.