А так вижу решение проблемы, которой я не понимаю, и мне сложно дать этому даже свою личную оценку, не то, что экспертную. Поэтому как статья о DDD - это слабо. В связи с этим, я оцениваю только кодогенерацию, она да, расписана хорошо, с чего начать, какие приемы, сложности и тд.
Китайские ученые создали 32-битный процессор толщиной в одну молекулу
Даже CAS уже отбирает чем слои в 1 атом легировать используя ИИ.
Естественно, все это скорее всего можно заменить на пептиды\белки )\
Тем более есть аналоги ДНК (с парой-тройкой доп. аминокислот).
И выращивай себе датацентры (очень хороший прирост по массе).
Для оптимизации конструкции ученые использовали машинное обучение, определяя лучшие комбинации материалов для каждого транзистора. Они создали и протестировали полный набор из 25 логических вентилей, из которых 18 оказались функциональными и были использованы в финальной конструкции чипа. Общий выход годных транзисторов при изготовлении чипа превысил 99,9%, а на уровне всего чипа составил 99,8%.
Т.е. определять, что не нужно показывать все 100 тысяч сообщений на форуме в веб-е научились очень давно.
Как раз по причине задержек из-за объема данных.
Пагинация - Это используют даже ребята из Google(!).
Веб, как и WPF/Winforms - только лишь UI, который по API что-то получает. Т.е. принцип тот же.
Хранить (кэшировать) объект и писать команды (и доставать недостающие их по RowVersion, и применять их к объекту) - тоже не сложно. (Гугл-таблицы и прочие карты).
Продукт японцев гораздо лучше, чем поделки лидеров ИИ, но далеко не SOTA.
Хоть 200 лямов, хоть 200 млрд (OpenAI, FTX Alphabet).
Или у вас есть технологии и шансы вернуть эти инвестиции, или 10-30% из них вы тратите на рекламу и рекламные статьи и обзоры (авось кто-то купит продукт).
Можно еще выпустить Токены Соленого, от фирмы Миллион Миллиардов, делать по ним анонсы и торговать ими.
Да, вам дали ссылку прямо на презентацию в KAIST (прямо нашел научрука и презентовал онлайн). Этот проект 2022 года лучше, чем поделия Google/OpenAI в 2025.
Найти даже ВУЗ\гранты довольно тяжело не говоря уже про венчуры, если вы не местный - тут Глобальный Мир дает сбой.
Местные фирмы и вузы в расчет можно вообще не брать. (KAIST топ-10 мира, МГУ\МГТУ - топ 100-200. Разница есть даже на уровне ВУЗ-ов. На уровне работ - разница еще больше)
В некоторых БД индексы просто отваливаются (не из-за фрагментации).
Всегда проверяйте Include (сколько их).
И сколько данных (в мегабайтах) возвращаете (с БД и с сервера через свой api).
include 10 элементов, связанных с 10 элементами это уже увеличение объёма данных в 100 раз. (вместо 100 кб за мс пришло 10 мегабайт за 2 секунды. Просто потому что у вас не RAID-6 на SSD, и еще 10 таких же запросов)
Поэтому обычно используют 2 маппинга - 1 облегченный на грид, второй - на полный обьект (в карточку обьекта)
Никто не предлагает делать полностью статическую или полностью динамическую конфигурацию.
Это вопрос веры
Вы можете делать полностью статическую конфигурацию и редактировать ее только через код, и это умно, если вы хотите, чтобы бизнес встал, когда разработчики ушли на больничный. Это повышает вашу ценность для бизнеса. Но это нечестная игра ;)
Наоборот. Коробочные решения для создания CRM, где объекты конфигурируются на лету или работают медленно, или стоят много или очень медленно развиваются.
Иногда все 3 разом.
Разработка же в доменных сущностях (добавляя их через классы) - Довольно быстро (если это DDD), и просто, да еще и быстро работает.
В ряде сценариев не существует даже отдаленно нужного функционала в готовых BPM/CRM системах, и расширять их практически невозможно (поэтому и ищут разработчиков микросервисов для любимых BPM Online/Directum и прочих).
Нет абсолютно ничего плохого в статической конфигурации (тех же магазинов и прочих мелких CRM). Даже 1С программируется через Конфигуратор.
Или вы говорите, что мне надо писать свой Apigee только потому что DDD не позволяет создать какой-то класс в Domain, и по нему что-то генерировать?
А в CRM мне значит нельзя сразу мои объекты в таблицы ложить из Domain, а надо сделать виртуальные таблицы, чтобы в рантайме можно было создавать таблицы и связи, и только потом работать с таким CRM?
Просто удивительно. Вы наверное Тролль?
https://habr.com/ru/articles/921552/comments/#comment_28483466
Об этом на форуме написали, в 2008.
Вот еще: http://www.electrik.org/forum/index.php?showtopic=61775&st=0
Сейчас мне лень искать литературу, но 2 разных двигателя на 1 вал - нормально.
Большой двигатель - большие потери на гистерезис.
Поэтому есть системы с 2 двигателями разного размера, которые работают на 1 вал (система регулирования момента с датчиком холла).
Тут то же самое, только 2 разных привода на 1 вал (обычно привод - двигатель и редуктор. Бывают комплектные приводы).
По батарее - даже на хабре делают эти BMS:
https://habr.com/ru/articles/920362/
Да, два асинхронника на 1 вал - откройте уже книги по Электроприводу
https://cccp3d.ru/topic/24805-два-двигателя-в-одном-приводе/
Обнаружение токовой перегрузки
То же самое, есть куча схем и без батарей, когда ток выше на 10% - выключаем все.
У них что, даже нет профильного образования или доступа в интернет?
Проектируйте как хотите.
Если пагинации нет,
или какого-то кэша к которому применяются команды с сервера (или события).
Думаю, объяснять про декартовый взрыв смысла нет.
https://learn.microsoft.com/en-us/ef/core/querying/single-split-queries
Равно и то, что в некоторых БД AsSplitQuery не работает, и там проблема решается через .AsTracking и .Load.
Кстати, самое смешное что AsSplitQuery\Load реально может ускорить запросы в сотню раз (1 мб вместо 100 из БД).
Но 9 из 10 команд продолжают использовать Dapper и не знают почему 2 инклуда норм а 3 уже не работают.
Что-то они странные
Даже CAS уже отбирает чем слои в 1 атом легировать используя ИИ.
Естественно, все это скорее всего можно заменить на пептиды\белки )\
Тем более есть аналоги ДНК (с парой-тройкой доп. аминокислот).
И выращивай себе датацентры (очень хороший прирост по массе).
https://nangs.org/news/it/kitajskie-uchenye-sozdali-32-bitnyj-protsessor-tolshchinoj-v-odnu-molekulu
Вот прямо Infinite Scroll в руку.
И 2 маппинга
https://habr.com/ru/articles/922672/comments/#comment_28497376
Вообще, это элементарные (базовые) вещи.
Т.е. определять, что не нужно показывать все 100 тысяч сообщений на форуме в веб-е научились очень давно.
Как раз по причине задержек из-за объема данных.
Пагинация - Это используют даже ребята из Google(!).
Веб, как и WPF/Winforms - только лишь UI, который по API что-то получает. Т.е. принцип тот же.
Хранить (кэшировать) объект и писать команды (и доставать недостающие их по RowVersion, и применять их к объекту) - тоже не сложно. (Гугл-таблицы и прочие карты).
https://microservice-api-patterns.org
Если менеджеры не понимают что такое пагинация и почему она необходима - значит это некомпетентные менеджеры.
Итог вы даже в статье описали - сокращения.
Обычно тривиальные вещи с неграмотным менеджментом лечатся вопросом "И где ты такое видел?"
Вы не High-end делаете (и вам не нужен оффлайн-кэш БД и подгрузка Diff-ов).
А пагинацию зачем придумали?
(Да ограничивать объем данных, чтобы по 1-100 мегабайт не гонять в том же веб-е)
А зачем делают различные маппинги (Лайт и фулл)?
(Да та же причина - основных полей дай бог половина, по которым идет работа и которые смотрят в гриде. Остальное идет в карточку обьекта)
Это - базовые принципы, на которых работает всё.
Даже поиск\автозаполнение - нашел 1000 элементов, вывел первые 10
Да, я вам уже написал что вам надо смотреть объём данных, планы запросов
https://habr.com/ru/articles/922672/#comment_28497376
Ниже пишут - еще и канал оказывает влияние. Да и в UI нигде нет больше 20-50 строк на странице, но мало ли.
https://habr.com/ru/articles/922672/#comment_28498602
За использование кодогенерации +.
Вам об этом и написали.
Продукт японцев гораздо лучше, чем поделки лидеров ИИ, но далеко не SOTA.
Хоть 200 лямов, хоть 200 млрд (OpenAI,
FTXAlphabet).Или у вас есть технологии и шансы вернуть эти инвестиции, или 10-30% из них вы тратите на рекламу и рекламные статьи и обзоры (авось кто-то купит продукт).
Можно еще выпустить Токены Соленого, от фирмы Миллион Миллиардов, делать по ним анонсы и торговать ими.
Да, вам дали ссылку прямо на презентацию в KAIST (прямо нашел научрука и презентовал онлайн). Этот проект 2022 года лучше, чем поделия Google/OpenAI в 2025.
Найти даже ВУЗ\гранты довольно тяжело не говоря уже про венчуры, если вы не местный - тут Глобальный Мир дает сбой.
Местные фирмы и вузы в расчет можно вообще не брать. (KAIST топ-10 мира, МГУ\МГТУ - топ 100-200. Разница есть даже на уровне ВУЗ-ов. На уровне работ - разница еще больше)
Gemini отстает даже от трансформера, прикрученного к простому солверу (A* BeamSearch, Random Initialization).
https://habr.com/ru/companies/bothub/news/921440/
Т.е. разработчики Gemini и ChatGPT вообще смутно представляют что они делают )
Утечки чего?
Продукты Google проигрывают даже гениям, читающим лекции (институтским поделкам).
OpenAI - Мы скачали Transformer (ex. T-9, автозаполнятор) из интернета, мы - гении ИИ.
Смотрите! Мы отбиваем ваши инвестиции!
Да, вы учтите, что у вас HDD читает дай бог 100 Мб\сек (если это не Raid-6 SSD).
Это - пиковая теоретическая скорость.
В реальности с БД может прилетать по 10-100 Мб.
Даже если эти 100 Мб и упаковываются в обьект - это уже секунда-другая только на работу EF.
Т.е. при 10 связанных объектах с еще 10 объектами вам просто придет в 100 раз больше строк (с полями основного и связанных объектов)
И есть подозрение что где-то что-то все-таки материализуется (при работе с IQueryable).
В некоторых БД индексы просто отваливаются (не из-за фрагментации).
Всегда проверяйте Include (сколько их).
И сколько данных (в мегабайтах) возвращаете (с БД и с сервера через свой api).
include 10 элементов, связанных с 10 элементами это уже увеличение объёма данных в 100 раз. (вместо 100 кб за мс пришло 10 мегабайт за 2 секунды. Просто потому что у вас не RAID-6 на SSD, и еще 10 таких же запросов)
Поэтому обычно используют 2 маппинга - 1 облегченный на грид, второй - на полный обьект (в карточку обьекта)
Во второй статье же обсуждали -
Да в большинстве CRM (ABP - BoilerTemplate) объекты тоже в коде задаются, и норм. Это дело вкуса и ТЗ.
А, ну и зачем аж целый протокол городить-то?
Лишняя безопасность?
Подключайтесь сразу к БД через VPN, выполняйте SQL запросы.
Не смотрели
https://github.com/esskar/Serialize.Linq
Делал то же самое, только в backend Web Api.
Сделал автогенерацию обьектов для поиска по сущностям (через И), и автогенерацию фильтров.
Для поиска обычно не нужны сложные условия (все через И).
Ну и конечные точки (без include) - CRUD, поиск.
Год - многовато.
Никто не предлагает делать полностью статическую или полностью динамическую конфигурацию.
Это вопрос веры
Наоборот. Коробочные решения для создания CRM, где объекты конфигурируются на лету или работают медленно, или стоят много или очень медленно развиваются.
Иногда все 3 разом.
Разработка же в доменных сущностях (добавляя их через классы) - Довольно быстро (если это DDD), и просто, да еще и быстро работает.
В ряде сценариев не существует даже отдаленно нужного функционала в готовых BPM/CRM системах, и расширять их практически невозможно (поэтому и ищут разработчиков микросервисов для любимых BPM Online/Directum и прочих).
Нет абсолютно ничего плохого в статической конфигурации (тех же магазинов и прочих мелких CRM). Даже 1С программируется через Конфигуратор.
И как вы предлагаете делать кодогенерацию?
Или вы говорите, что мне надо писать свой Apigee только потому что DDD не позволяет создать какой-то класс в Domain, и по нему что-то генерировать?
А в CRM мне значит нельзя сразу мои объекты в таблицы ложить из Domain, а надо сделать виртуальные таблицы, чтобы в рантайме можно было создавать таблицы и связи, и только потом работать с таким CRM?
Значит ли это, что создатели ABP - полные дураки?
Ведь там эти, доменные сущности приходится в коде создавать и перекомпилировать проект.