Можно еще редис/очереди + пакетная вставка. Типа ридер, который сгребает данные и пакетами вставляет, если данных нет, то заканчивает. Как появятся, то запуск вставки. Все же бд может и сменится.
Если у вас фрагменты вашего кода будут решать одну специализированную задачу, то каши не будет. То за что вы топите подталкивает создавать именно не такие фрагменты программного кода, а кашу-малашу.
Вы рано или поздно поймете о чем вам говорят, поэтому дискуссию прекращаю.
Ну если писать периодически код и рефачить, то будет понятно. Виртуальные методы совсем не по факту тоже самое что и интерфейс, разве что для среды.
По факту факта это каша: определить один механизм в одном классе, и в подклассах его наращивать. Лучше не страдать такой шизой, а просто разделить ответственность между специализированными типами.
" И большинство из них просто не умеют его готовить. "
Ахах. А зачем уметь создавать химеру? Хотя учитывая ваш ответ выше, вы просто не понимаете о чем я...
Описание паттерна ок. Только в реальном коде не надо это использовать. Чтоб не порождать тонны не анализируемого кода. Сперва один производный класс, потом другой. Потом где то через base. и.т.д. Такие подходы приводят к коду не поддающемуся рефакторингу.
Лучше заведите интерфейс, определите там что надо, реализуйте. А потом внедрите его в класс с логикой, которая будет работать с методами. (это паттерн стратегия, инверсия зависимости)
Часто это показывает, что зависимости неправильно расставлены, и таким образом пытаются отстранится от инфраструктурных частей. От которых вообще не надо зависеть.
Вы тогда ограничиваете себя правилами кодогенерацией фреймворка. Код который нельзя править самому, ну не абсурд ли? Вот возьмите обычную задачу. Допустим там модель с 20ю полями и еще пара вложенных типов. Это сделать используя любое IDE и мультикаретку - пара минут. И нет никаких волшебст и зависимостей. Все. Вот он код. Захотел переименовал, захотел прописал еще что-то там.
Люди придумывают себе проблемы из ниоткуда. Все ваши фреймворки для маппинга приводят к проблемам. Это неявно, это сложно расширять правилами. Сложно найти то место где это магически сделано, используя простой переход к реализации. Экономите пару минут, но потом тратите неделю на фикс. Можно просто использовать, например, IConvert<TFrom, TTo>. И внедрять куда надо. Это никогда не сломается при переименовании или апдейте фреймворка. И это можно мокать, если есть на то потребность в тесте. Если IConvert лень часто внедрять, и моментное удобство дороже быстрого перехода к реализации, то можно обернуть а сервайслокатор, внедрить его и вызывать для всех маппингов (что по мне не перевешивает удобство перехода к реализации).
Что за навык "тестирование"? Вы тестировщик? Программирование состоит не только из локальных алгоритмов. Большая часть времени это организация архитектуры, рефакторинг и здравые решения, на одной внимательности вы не выедете, если вдруг у вас получится спагетти код который будет без ошибок. Бинарный поиск или быстрая сортировка не скажут вам как сделать не спагетти.
Да и это банально не интересно набивать алгоритмы вместо изучения интересных и полезных кейсов. Очнитесь.
Выходит в ней по правде очень много света
Можно еще редис/очереди + пакетная вставка. Типа ридер, который сгребает данные и пакетами вставляет, если данных нет, то заканчивает. Как появятся, то запуск вставки. Все же бд может и сменится.
А что там в ней? Материя так же вращается, но просто мы не видим из-за того что свет не улетает? Или это уже плотный атом?
Если у вас фрагменты вашего кода будут решать одну специализированную задачу, то каши не будет. То за что вы топите подталкивает создавать именно не такие фрагменты программного кода, а кашу-малашу.
Вы рано или поздно поймете о чем вам говорят, поэтому дискуссию прекращаю.
Ну если писать периодически код и рефачить, то будет понятно. Виртуальные методы совсем не по факту тоже самое что и интерфейс, разве что для среды.
По факту факта это каша: определить один механизм в одном классе, и в подклассах его наращивать. Лучше не страдать такой шизой, а просто разделить ответственность между специализированными типами.
Ахах. А зачем уметь создавать химеру? Хотя учитывая ваш ответ выше, вы просто не понимаете о чем я...
Недавно добавлял ef core sql lite на maui. Это делается сильно проще. Буквально что бы это описать надо пара сток:
проект с моделями и миграшками
проект чисто для генерации миграций
для генерации:
dotnet ef migrations --project ПервыйПроект --startup-project ВторойПроект add Миграция.
И нет необходимости засорять конструктор. Просто обычно корнфигурируется.
Описание паттерна ок. Только в реальном коде не надо это использовать. Чтоб не порождать тонны не анализируемого кода. Сперва один производный класс, потом другой. Потом где то через base. и.т.д. Такие подходы приводят к коду не поддающемуся рефакторингу.
Лучше заведите интерфейс, определите там что надо, реализуйте. А потом внедрите его в класс с логикой, которая будет работать с методами. (это паттерн стратегия, инверсия зависимости)
ну это не вызов крестов из шарпа, как указано в заголовке на картинке...
Ну он как бы и не особо тяготел к самому языку (c#), некоторые его предложения по его использованию сомнительны.
Какой свич еще? Бесконечный итератор это когда movenext будет тру отдавать всегда.
И мы как бы бредовые идеи и рассматриваем.
Цель: нанять такого же идиота как и наниматель.
Вас спросили как бы вы реализовали, а НЕ как стоит реализовывать. Из упоротого можно еще: бесконечный итератор и рекурсивный вызов.
Очень больно пытаться понять то что вы написали... Используйте фабрику и стратегию.... И имена классов пишите с заглавной буквы.
Занимайтесь тем что вам по душе.
Если вы измените его, то следующая генерация кода его перезатрет.
Часто это показывает, что зависимости неправильно расставлены, и таким образом пытаются отстранится от инфраструктурных частей. От которых вообще не надо зависеть.
Вы тогда ограничиваете себя правилами кодогенерацией фреймворка. Код который нельзя править самому, ну не абсурд ли? Вот возьмите обычную задачу. Допустим там модель с 20ю полями и еще пара вложенных типов. Это сделать используя любое IDE и мультикаретку - пара минут. И нет никаких волшебст и зависимостей. Все. Вот он код. Захотел переименовал, захотел прописал еще что-то там.
Люди придумывают себе проблемы из ниоткуда. Все ваши фреймворки для маппинга приводят к проблемам. Это неявно, это сложно расширять правилами. Сложно найти то место где это магически сделано, используя простой переход к реализации. Экономите пару минут, но потом тратите неделю на фикс. Можно просто использовать, например, IConvert<TFrom, TTo>. И внедрять куда надо. Это никогда не сломается при переименовании или апдейте фреймворка. И это можно мокать, если есть на то потребность в тесте. Если IConvert лень часто внедрять, и моментное удобство дороже быстрого перехода к реализации, то можно обернуть а сервайслокатор, внедрить его и вызывать для всех маппингов (что по мне не перевешивает удобство перехода к реализации).
Что за навык "тестирование"? Вы тестировщик? Программирование состоит не только из локальных алгоритмов. Большая часть времени это организация архитектуры, рефакторинг и здравые решения, на одной внимательности вы не выедете, если вдруг у вас получится спагетти код который будет без ошибок. Бинарный поиск или быстрая сортировка не скажут вам как сделать не спагетти.
Да и это банально не интересно набивать алгоритмы вместо изучения интересных и полезных кейсов. Очнитесь.
Вообще то мешает, общий ресурс время.