А зачем в go использовать модель акторов? Я к тому, что есть горутины и рекомендуемый способ коммуникации между ними - каналы. Не будет ли это овер-инженерингом или все таки есть плюсы?
А не смотрели какие-то готовые расширения для EF? Настраивали как-то DbContext перед запуском миграции? Например, такая настррйка QueryTrackingBehavior.NoTracking. Или при определении запроса AsNoTracking? И интересно увидеть метрики. Например, время переноса записей из таблицы одной БД в другую. Как время меняется в зависимости от количества записей в таблице или каких-то еще параметров? Общее время для переноса данных из всех таблиц.
Странная статья. Откровенно бесполезная. Все эти фреймворки можно найти на go-awesome или на подобных ресурсах. Куда интереснее обзор или опыт использования с описанием плюсов и минусов, каких-то фишек, хаков и т.д. Расскажите, а что используете вы? Встречный вопрос. А вы расскажите с какой целью написали и опубликовали данную статью? Кроме hr- и маркетинговых целей :-)
Для меня ключевыми преимуществами 740 являются: синхронизация чтения с разных устройств и наличие кнопок для перелистывания и в целом очень удачная эргономика. По мне это самый оптимальный формат для электронной книги. Ключевые недостатки: очень хрупкая книга и явные проблемы с софтом. У меня книга начинает тормозить, если уровень заряда на половине или меньше.
Обобщения/дженерики, если объективно, нужны в общем случае и чаще всего для базовых коллекций и алгоритмов. Например: списки, деревья, сортировка, поиск и т.д. И их отсутствие вовсе не ограничение для использования DDD или других концепций. Да и без DDD так называемая бизнес-логика чаще всего основана на конкретном описании, а не на обобщении.
Нужен или не нужен зависит от контекста и конкретной задачи. А инструменты есть. Из адекватных есть facebook/ent отлично справляется с сохранением графа объектов.
А зачем в go использовать модель акторов? Я к тому, что есть горутины и рекомендуемый способ коммуникации между ними - каналы. Не будет ли это овер-инженерингом или все таки есть плюсы?
DI - это все таки принцип, а не контейнер для автоматического разрешения зависимостей. Так или иначе внедрение зависимостей в go используется.
А не смотрели какие-то готовые расширения для EF? Настраивали как-то DbContext перед запуском миграции? Например, такая настррйка QueryTrackingBehavior.NoTracking. Или при определении запроса AsNoTracking? И интересно увидеть метрики. Например, время переноса записей из таблицы одной БД в другую. Как время меняется в зависимости от количества записей в таблице или каких-то еще параметров? Общее время для переноса данных из всех таблиц.
Странная статья. Откровенно бесполезная. Все эти фреймворки можно найти на go-awesome или на подобных ресурсах. Куда интереснее обзор или опыт использования с описанием плюсов и минусов, каких-то фишек, хаков и т.д. Расскажите, а что используете вы? Встречный вопрос. А вы расскажите с какой целью написали и опубликовали данную статью? Кроме hr- и маркетинговых целей :-)
Для меня ключевыми преимуществами 740 являются: синхронизация чтения с разных устройств и наличие кнопок для перелистывания и в целом очень удачная эргономика. По мне это самый оптимальный формат для электронной книги. Ключевые недостатки: очень хрупкая книга и явные проблемы с софтом. У меня книга начинает тормозить, если уровень заряда на половине или меньше.
Обобщения/дженерики, если объективно, нужны в общем случае и чаще всего для базовых коллекций и алгоритмов. Например: списки, деревья, сортировка, поиск и т.д. И их отсутствие вовсе не ограничение для использования DDD или других концепций. Да и без DDD так называемая бизнес-логика чаще всего основана на конкретном описании, а не на обобщении.
Нужен или не нужен зависит от контекста и конкретной задачи. А инструменты есть. Из адекватных есть facebook/ent отлично справляется с сохранением графа объектов.
А можно аргументы? Почему DDD плох для микросервисов?
А не планируется перевод книги Rust in action?