Но какой смысл? Запилить такое вручную еще было бы удивительно, а так, для ИИ реализовать давно известный алгоритм на полном по Тюрингу языке не особо сложно. И сколько времени занимает генерация одного кадра?
Окей, классно, но как это сделать? Я ждал, что автор не просто подсветит проблему, а покажет конкретный пример ее решения, но есть ощущение, что это далеко не всегда возможно. Если у нас объекты появляются или скрываются в результате анимации, они в какой-то момент неизбежно будут обрезаны, или замылены, или сжаты. Вещи, красивые в движении, не всегда красивы в статике (и наоборот), в частности человеческая мимика.
код обмазанный unsafe чуть меньше, чем полностью, будет быстрее
Во-первых, это не факт. Использование unsafe может мешать JIT проводить оптимизации. Во-вторых, если код густо обмазан unsafe, есть подозрение что выбор C# как языка или .NET как платформы для этого проекта был ошибочным.
Если судить по бенчмаркам Techempower, нельзя сказать, что джава заметно отстает от дотнета - скорее даже наоборот. Получается, там придумали, как это сделать достаточно оптимизированно, не перекладывая низкоуровневые концепции типа ref/value типов на разработчика. За это им респект
А версия no sql была без ef? Как бы получается, что вопросы эти касаются именно ef. Грубо говоря, для get-by-id - если в первой реализации вы не трекали изменения, значит во второй используете as-no-tracking
Да, изначально была самопальная реализация репозитория. Разумеется, можно было бы везде использовать AsNoTracking, но это противоречит принципам EF и приводит к неоптимальному коду, о чем я говорил выше: придется создавать контекст отдельно на каждую операцию, явно прикреплять к нему объект и т.д.
чистый репозиторий + unit of work дает больше гибкости, чем orm
EF сам по себе уже предоставляет эти абстракции: DbContext = Unit of work, DbSet<T> = Repository.
если был включен трекинг - метод update вырождается до вызова save changes
Верно - в таком контексте метод update вообще не имеет смысла, потому что обновление состояния происходит при изменении любого свойства (в том числе произвольного другого объекта, входящего в отслеживаемый граф)
Проблемы в любом случае будут, просто потому что перевести нетривиальный проект с одной базы на другую - это само по себе сложная инженерная задача, вне зависимости от используемой методологии, DDD или что угодно еще. Репозиторий позволяет разве что упростить миграцию в одном слое за счет усложнения другого: условно, логика приложения переезжает вообще без изменений, зато на слое доступа к данным теперь творится ад. Во многих случаях это оправдано, но нужно учесть, что некоторые проблемы (в частности с производительностью) с такими ограничениями становятся вообще нерешаемыми, поэтому менять интерфейс в любом случае придется
пишем новую реализацю репозитория, подставляем в алиас новый репозиторий и все
репозиторий явно не самый сложный паттерн
Темболее что это супер легко я не писал.
Судя по вашему вопросу в отдельной ветке про “маппинг для IQueryable” я могу сделать вывод, что вы вообще не имеете никакого представления о C# \ EF, однако решили поучаствовать в дискуссии, цитируя прописные истины. А как только я предложил обсудить вопрос по существу, запас тотчас иссяк и началось - “вопрос недостаточно конкретный”, “я не я и лошадь не моя” и т.д… Жаль, что так получилось.
Так вы же выше утверждаете, что всё очень просто, и если не получается сделать красиво - это просто skill issue. Вот я вам пример задачи привожу, минимальный и конкретный: как бы вы в этом случае сделали красиво? Только по существу, пожалуйста, а не цитаты абстрактных определений из книг
Окей, вот конкретный пример. У нас был репозиторий примерно такого вида, когда первая версия проекта работала поверх CosmosDB:
interface IRepository<T>
{
T GetById(int id);
void Remove(int id);
void Update(int id, T value);
}
Все очень просто: взял запись, поправил, сохранил. С NoSQL отлично работает. Дальше пытаемся переехать на SQL + EF, и сразу возникают вопросы:
Внутри GetById нужно делать AsTracking или AsNoTracking? Оба варианта имеют проблемы с производительностью, третий вариант “выставить флаг наружу” нарушает абстракцию
Remove должен вызывать ExecuteDelete (быстро, но ломает стейт) или SaveChanges (требует подгрузки, может применить другие изменения)?
Нужно поменять две сущности вместе, атомарно, в одной транзакции. В интерфейсе такого нет - не было нужно, база не умеет и т.д., что делать? Нарушить абстракцию и использовать транзакции, или писать саги-реверты по старинке с горой бойлерплейта?
И это только то, что пришло в голову, на двух достаточно хорошо известных технологиях. А если через два года потребуется переехать на что-то еще более экзотическое?
В том и проблема, что “элегантно и удобно” на практике не получается. Нельзя заранее заложить такой интерфейс, чтобы в него хорошо ложился и текущий, и любой будущий источник данных. Даже уже SQL и NoSQL слишком разные подходы, чтобы их можно было унифицировать единым интерфейсом, не жертвуя производительностью.
На моем опыте мысль “репозиторий позволит абстрагироваться от базы данных” - это несбыточная мечта, которая очень дорого обходится в процессе. Если мы говорим о смене одной SQL-базы на другую, то современный EF как правило справляется достаточно хорошо - в разных проектах пробовали разные сочетания SQL Server, PostgreSQL и SQLite, потребовались только минимальные модификации (и то в основном в коде миграций). Вообще говоря, у SQLite in-memory достаточно высокая совместимость с PostgreSQL, чтобы ее можно было использовать в юнит-тестах вместо живой базы на 99% тестах - очень сильно экономит время по сравнению с теми же testcontainers, на которых прогоняется оставшийся 1% сложных тестов. Ну а пытаться написать абстракцию, которая одинаково хорошо скрывает как SQL, так и NoSQL-базы, имхо гиблое дело - либо абстракция будет течь, либо это будет работать страшно неэффективно.
В каком мире доход провинции может зависеть от налогов ее соседей??? С одинаковыми коэффициентами между всеми элементами в кольце и на всех слоях? Это абсурд, который нейросеть видимо сначала нагаллюцинировала, а теперь продолжает на голубом глазу расписывать длинными предложениями с примерами. Соответственно, остальные примеры также могут быть натягиванием совы на глобус.
А объясните тогда, пожалуйста, пример 2 из области GameDev, где провинции и налоги, как это вообще работает? Доход провинции 1 зависит от налога провинций 1, 2, 3, 4? Как именно зависит, с какими коэффициентами?
В вашем примере с app pipeline pull --fetch commit -m "fix" push run вы объявляете и run, и --fetch параметром. Непонятно, как оно делит поток на команды и их аргументы, и что будет делать в случае неоднозначности (например, если объявить [ArgsPipelineCommand("run")], то оно воспримется как отдельная команда или как параметр в ExecConfig?
Спасибо за вашу работу. Выглядит очень стильно и открывается действительно ощутимо быстрее, чем VS Code (хотя Zed еще быстрее).
Нашел несколько багов:
Не работает double click на заголовке - в Windows я ожидаю, что приложение откроется на полный экран
Странно работает выделение внутри блоков кода - начало выделения не совпадает с местом, где находится курсор. Чем дальше от начала текста начинаешь выделять, тем сильнее несовпадение.
Хотелось бы:
Возможность отображать текст на полную ширину (максимальная доступная сейчас занимает 1/4 от моего экрана)
Возможность скроллить текст после клика на колесо мыши, как в браузере
Это не чистый SQL, а диалект ClickHouse. Даже в readme написано, что они пытались запускать на других базах и оно не работает
Но какой смысл? Запилить такое вручную еще было бы удивительно, а так, для ИИ реализовать давно известный алгоритм на полном по Тюрингу языке не особо сложно. И сколько времени занимает генерация одного кадра?
Значит продадут неофициально, со скидкой, каким-нибудь китайцам - не выкидывать же партию
Окей, классно, но как это сделать? Я ждал, что автор не просто подсветит проблему, а покажет конкретный пример ее решения, но есть ощущение, что это далеко не всегда возможно. Если у нас объекты появляются или скрываются в результате анимации, они в какой-то момент неизбежно будут обрезаны, или замылены, или сжаты. Вещи, красивые в движении, не всегда красивы в статике (и наоборот), в частности человеческая мимика.
Во-первых, это не факт. Использование unsafe может мешать JIT проводить оптимизации. Во-вторых, если код густо обмазан unsafe, есть подозрение что выбор C# как языка или .NET как платформы для этого проекта был ошибочным.
Если судить по бенчмаркам Techempower, нельзя сказать, что джава заметно отстает от дотнета - скорее даже наоборот. Получается, там придумали, как это сделать достаточно оптимизированно, не перекладывая низкоуровневые концепции типа ref/value типов на разработчика. За это им респект
Отвечу сразу на оба комментария:
Да, изначально была самопальная реализация репозитория. Разумеется, можно было бы везде использовать
AsNoTracking, но это противоречит принципам EF и приводит к неоптимальному коду, о чем я говорил выше: придется создавать контекст отдельно на каждую операцию, явно прикреплять к нему объект и т.д.EF сам по себе уже предоставляет эти абстракции:
DbContext= Unit of work,DbSet<T>= Repository.Верно - в таком контексте метод update вообще не имеет смысла, потому что обновление состояния происходит при изменении любого свойства (в том числе произвольного другого объекта, входящего в отслеживаемый граф)
Проблемы в любом случае будут, просто потому что перевести нетривиальный проект с одной базы на другую - это само по себе сложная инженерная задача, вне зависимости от используемой методологии, DDD или что угодно еще. Репозиторий позволяет разве что упростить миграцию в одном слое за счет усложнения другого: условно, логика приложения переезжает вообще без изменений, зато на слое доступа к данным теперь творится ад. Во многих случаях это оправдано, но нужно учесть, что некоторые проблемы (в частности с производительностью) с такими ограничениями становятся вообще нерешаемыми, поэтому менять интерфейс в любом случае придется
Судя по вашему вопросу в отдельной ветке про “маппинг для IQueryable” я могу сделать вывод, что вы вообще не имеете никакого представления о C# \ EF, однако решили поучаствовать в дискуссии, цитируя прописные истины. А как только я предложил обсудить вопрос по существу, запас тотчас иссяк и началось - “вопрос недостаточно конкретный”, “я не я и лошадь не моя” и т.д… Жаль, что так получилось.
Так вы же выше утверждаете, что всё очень просто, и если не получается сделать красиво - это просто skill issue. Вот я вам пример задачи привожу, минимальный и конкретный: как бы вы в этом случае сделали красиво? Только по существу, пожалуйста, а не цитаты абстрактных определений из книг
Окей, вот конкретный пример. У нас был репозиторий примерно такого вида, когда первая версия проекта работала поверх CosmosDB:
Все очень просто: взял запись, поправил, сохранил. С NoSQL отлично работает. Дальше пытаемся переехать на SQL + EF, и сразу возникают вопросы:
Внутри
GetByIdнужно делатьAsTrackingилиAsNoTracking? Оба варианта имеют проблемы с производительностью, третий вариант “выставить флаг наружу” нарушает абстракциюRemoveдолжен вызыватьExecuteDelete(быстро, но ломает стейт) илиSaveChanges(требует подгрузки, может применить другие изменения)?Нужно поменять две сущности вместе, атомарно, в одной транзакции. В интерфейсе такого нет - не было нужно, база не умеет и т.д., что делать? Нарушить абстракцию и использовать транзакции, или писать саги-реверты по старинке с горой бойлерплейта?
И это только то, что пришло в голову, на двух достаточно хорошо известных технологиях. А если через два года потребуется переехать на что-то еще более экзотическое?
В том и проблема, что “элегантно и удобно” на практике не получается. Нельзя заранее заложить такой интерфейс, чтобы в него хорошо ложился и текущий, и любой будущий источник данных. Даже уже SQL и NoSQL слишком разные подходы, чтобы их можно было унифицировать единым интерфейсом, не жертвуя производительностью.
На моем опыте мысль “репозиторий позволит абстрагироваться от базы данных” - это несбыточная мечта, которая очень дорого обходится в процессе. Если мы говорим о смене одной SQL-базы на другую, то современный EF как правило справляется достаточно хорошо - в разных проектах пробовали разные сочетания SQL Server, PostgreSQL и SQLite, потребовались только минимальные модификации (и то в основном в коде миграций). Вообще говоря, у SQLite in-memory достаточно высокая совместимость с PostgreSQL, чтобы ее можно было использовать в юнит-тестах вместо живой базы на 99% тестах - очень сильно экономит время по сравнению с теми же testcontainers, на которых прогоняется оставшийся 1% сложных тестов. Ну а пытаться написать абстракцию, которая одинаково хорошо скрывает как SQL, так и NoSQL-базы, имхо гиблое дело - либо абстракция будет течь, либо это будет работать страшно неэффективно.
Позовите пожалуйста оператора - я хочу пообщаться с живым человеком, а не с ллмкой.
В каком мире доход провинции может зависеть от налогов ее соседей??? С одинаковыми коэффициентами между всеми элементами в кольце и на всех слоях? Это абсурд, который нейросеть видимо сначала нагаллюцинировала, а теперь продолжает на голубом глазу расписывать длинными предложениями с примерами. Соответственно, остальные примеры также могут быть натягиванием совы на глобус.
А объясните тогда, пожалуйста, пример 2 из области GameDev, где провинции и налоги, как это вообще работает? Доход провинции 1 зависит от налога провинций 1, 2, 3, 4? Как именно зависит, с какими коэффициентами?
Не нашел ни в одном примере, как задаются связи между элементами слоя и между слоями
В вашем примере с
app pipeline pull --fetch commit -m "fix" push runвы объявляете иrun, и--fetchпараметром. Непонятно, как оно делит поток на команды и их аргументы, и что будет делать в случае неоднозначности (например, если объявить[ArgsPipelineCommand("run")], то оно воспримется как отдельная команда или как параметр вExecConfig?В оригинале режим назывался Nerdy, я не знаю как именно он был переведен на русский т.к. его выпилили и проверить уже нельзя
Спасибо за вашу работу. Выглядит очень стильно и открывается действительно ощутимо быстрее, чем VS Code (хотя Zed еще быстрее).
Нашел несколько багов:
Не работает double click на заголовке - в Windows я ожидаю, что приложение откроется на полный экран
Странно работает выделение внутри блоков кода - начало выделения не совпадает с местом, где находится курсор. Чем дальше от начала текста начинаешь выделять, тем сильнее несовпадение.
Хотелось бы:
Возможность отображать текст на полную ширину (максимальная доступная сейчас занимает 1/4 от моего экрана)
Возможность скроллить текст после клика на колесо мыши, как в браузере
Подсветку синтаксиса для блоков кода
Можно будет эмулировать Kinect с помощью камеры и лидара?