romaro

Это, по сути, наследование. Абстрактный класс-предок (поставщик) и конкретные классы-потомки (физлицо, ИП, организация). Наследование обычно выражается в структуре БД так: создаётся таблица "Поставщик", содержащая общие для всех классов поля и имеющая свой ключ.
Затем под каждый класс-потомок создаётся отдельная таблица, содержащая сведения, уникальные для этого класса. В этой таблице первичный ключ одновременно является внешним ключом, ссылающимся на таблицу "Поставщик". Иными словами, в таблице-потомке могут быть только записи с ключами, которые есть в таблице "Поставщик", а для каждой записи в "Поставщик" будет не более одной записи в таблице-потомке.

В таблице "Поставщик" также может быть поле, указывающее на конкретный тип поставщика (физлицо, ИП, организация), т.е. в какой таблице искать остальные данные. Наличие или отсутствие этого поля - вопрос вкуса. В принципе, если нам нужны сведения о конкретном типе поставщика, мы можем попытаться сделать INNER JOIN с нужной конкретной таблицей. Это отсеет все записи других типов.
Такой подход (без поля типа) позволяет избежать противоречий, когда запись находится в одной таблице-потомке, а поле указывает на другую. Но с другой стороны, если мы не знаем, какой конкретный тип у данного поставщика, нам придётся либо перебирать таблицы-потомки в рамках нескольких запросов к БД, либо делать LEFT JOIN со всеми таблицами-потомками, и смотреть, какие поля не будут NULL.

Слабая сторона такой схемы в том, что связь по внешнему ключу не запрещает существование записей в нескольких таблицах-потомках, ссылающихся на одну и ту же запись в "Поставщике". Это придётся контролировать отдельно, триггерами или хранимыми процедурами.

1. WPF немного адаптирован для MVVM, но это не обязательно — масса примеров в родной документации не использует никакого MVVM. Так что я бы не связывал выбор использования MVVM с WPF.
   
2. Есть готовые библиотеки для WinForms, которые умеют делать легкий MVVM. Лично я, например, работал с DevExpress и на мой взгляд, из коробки он дает даже больше, чем WPF (например, есть встроенные сервисы работы с попап окнами). Так что использовать MVVM на WinForms не сложнее, чем на WPF.
   
3. И раз мы отделили вопрос MVVM от WPF/WF, нужно принципиально решать вопрос использовать ли MVVM в конкретном проекте.
   
4. И, собственно, вопрос использование MVVM имеет плюсы и минусы. Плюсы — сопротивление хаосу при массированных изменениях кода, уменьшение человеческого труда при тестировании. Минусы — больше кодинга (накладные расходы на раздельную реализацию VM + юнит-тесты), не устраняет ручное тестирование до конца. Использовать MVVM без юнит-тестов смысла особо не вижу — кодить больше, выгоды никакой.
   

Лично мое мнение — если нужна простая утилита «для себя», которую один раз написали и не трогают, я бы писал быстро (без MVVM и тестов). А если её будут менять, в том числе другие разработчики, а цена ошибки — деньги (например, если админятся данные клиентов по контрактам), то лучше MVVM и тесты.

А что сразу не делать проект на WPF? Тем более он затачивался под MVVM. MVVM в WinForms можно, но немного с костылями.

Нет, оно там просто не нужно - достаточно просто правильно структурировать приложение. В WF вполне достаточно просто разделить логику приложения и логику самого интерфейса. Нужен нестандартный контрол со своим поведением? Отпочковываем класс от Control и вперед. Логика самого интерфейса вполне нормально живет в самих классах элементов управления (в терминах MVVM это два в одном View + ViewModel). Например, реальный случай из практики: запилил WF приложение по выданному дизайну - его потестили и почти сразу дизайнер нарисовал полностью новый дизайн; ввиду увеличения фишечек, рюшечек и всего остального (а так же тормозов древнего легаси наследия WF, конечно же) - я просто перенес файлы с логикой из WF проекта в WPF проект в модели и запилил новый GUI на WPF.

В общем, условно, такой код, глядя на который, даже самые суровые критики не могли бы найти к чему придраться.

Всегда можно к чему-то придраться.
Качество архитектуры можно понять только в динамике - легко ли вносить изменения в продукт, или сложно.
А так есть eShopOnWeb и eShopOnContainers

Вообще тут напрашивается перегрузка для каждого T:

public void SetStrategy(Action<SomeOne> action) {
  _someOne = action;
}

public void SetStrategy(Action<SomeTwo> action) {
  _someTwo = action;
}

Но можно и так, если прям необходимо один метод (стоит задуматься, а действительно ли необходимо):

switch(executor) {
  case Action<SomeOne> one:
    _someOne = one;
    break;
  case Action<SomeTwo> two:
    _someTwo = b;
    break;
  default:
    throw new NotSupportedException($"{typeof(T).FullName} is not supprted");
}

Перегрузка - самый оптимальный вариант.

чтобы при публикации она попадала в exe-контейнер?

Положи её в папку с проектом.
Поставь файлу свойство, что его надо при сборке копировать.
Поставь в проекте свойство IncludeNativeLibrariesForSelfExtract

Реализуй вот это
Задача
Доработка сканера серийных номеров с этикеток.
Цель: доработать существующий сканер этикеток.
1. Система должна давать возможность нахождения и распознавания серийного номера независимо от иного текста, цвета фона, кол-ва символов S/N.
2.Скорость - не менее 1,5 сек на объект
3.Точность распознавания - не менее 96%
4. Динамический выбор области сканирования с помощью татч-скрина
5. Системные требования IOS, Android.

Это конечно перебор для вас в области 4,5
Но просто сделай на основе фото.
Как заготовку сможешь использовать это, баркоды пакеты
ZXing.Net
ZXing.Net.Bindings.CoreCompat.System.Drawing

Серийный номер Tesseract

https://github.com/vkorotenko/VueRecaptcha