Наткнулся на очередную задумку Убивец 1С

Проблема в том, что нет открытой системы для ведения учета.
Все со своим ограниченным языком, не расширяемо.

По сути можно создать систему классов, отобразив её на БД и у людей под рукой будет система учета
которую они могут расширять и применять различные инструменты.

linq2db интересен тем, что он расширяем и можно заточить методы под определенную иерархию классов.

В свое время создавал классы по "классам" 1С и строил запросы Linq
https://infostart.ru/public/402038/
https://infostart.ru/public/402433/

Обработки для формирования классов можно скачать здесь
http://files.rsdn.org/19608/CodeFirstTo1C.zip
http://files.rsdn.org/19608/CodeFirstTo83.zip

В 1С есть поля неопределенного типа, есть виртуальные таблицы остатки и обороты.
Для выборки неопределенных полей подходит CASE WHEN, который можно организовать на новом switch паттерн матчинг.
Для ограничения типов подойдут и юнионы из C#9

По большому счету можно обойтись и без визуальной части конструирования классов,
но нужно запоминать изменения при реструктуризации. Проблем нет если сравнить с текущей БД.

Интерес больше представляют остатки и обороты
Да вот еще в 1С ввели понятие виртуальная таблица остаткт и обороты
http://e-1c.ru/node/76

Эффективность обращения к виртуальным таблицам во многом зависит от того, как построено обращение к этой таблице. Стандарт Обращения к виртуальным таблицам описывает общие требования и рекомендации по работе с виртуальными таблицами. В этом стандарте изложены дополнительные рекомендации по повышению эффективности обращения к виртуальной таблице Остатки регистров накопления и бухгалтерии.
При обращении к любой виртуальной таблице платформа 1С:Предприятие генерирует запрос к СУБД, содержащий вложенный запрос. Самым эффективным вложенным запросом для чтения остатков будет чтение хранимой таблицы текущих остатков без применения группировки по измерениям. Платформа 1С:Предприятие сгенерирует такой запрос, если будут соблюдены все перечисленные ниже условия:
получение остатков ведется без указания даты;
не используется разделение итогов (необходимо учитывать при использовании такого режима может снижаться параллельность записи в регистр. См. также Режим разделения итогов для регистров накопления, Режим разделения итогов для регистров бухгалтерии);
внешний по отношению к виртуальной таблице запрос использует все измерения (в предложении ВЫБРАТЬ или в условиях соединения).
Пример.
Регистр накопления ОстаткиТовара содержит два измерения: Склад и Номенклатура, а также ресурс Количество. Необходимо запросом получить список всей номенклатуры, с указанием количества товаров на конкретном складе.
НЕПРАВИЛЬНО

ВЫБРАТЬ
 СпрНоменклатура.Ссылка КАК Товар, 
 ЕСТЬNULL(ОстаткиТоваров.Остаток, 0 ) КАК Остаток
ИЗ
Справочник.Номенклатура КАК СпрНоменклатура
 ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Остатки(&СегодняшняяДата, Склад = &Склад) КАК ОстаткиТоваров
ПО ОстаткиТоваров.Номенклатура = СпрНоменклатура.Ссылка

В этом запросе:
в условия виртуальной таблицы передана дата, поэтому будет использована не только хранимые таблицы остатков, но и таблица движений. Т.к. необходимо получить текущие остатки, то дату в запрос передавать не нужно;
измерение Склад не используется во внешнем по отношению к виртуальной таблице запросе, поэтому вложенный запрос остатков будет содержать группировку этому измерению.
ПРАВИЛЬНО

ВЫБРАТЬ
 СпрНоменклатура.Ссылка КАК Товар, 
 ЕСТЬNULL(ОстаткиТоваров.Остаток, 0 ) КАК Остаток
ИЗ
Справочник.Номенклатура КАК СпрНоменклатура
 ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Остатки(, Склад = &Склад) КАК ОстаткиТоваров
ПО ОстаткиТоваров.Номенклатура = СпрНоменклатура.Ссылка
 И ОстаткиТоваров.Склад = &Склад

Указав в выбрать определеннные поля измерений они же являются и группировкой.
Можно рассчитать остатки на любой момент времени

Если будет такая система классов и примитивный пример для ведения учета на складе, то интерес к linq2db возрастет.

https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-efcore-5-0-preview-6/

Simplify case blocks
EF Core now generates better queries with CASE blocks. For example, this LINQ query:

context.Weapons
    .OrderBy(w => w.Name.CompareTo("Marcus' Lancer") == 0)
    .ThenBy(w => w.Id)

Was on SQL Server formally translated to:

SELECT [w].[Id], [w].[AmmunitionType], [w].[IsAutomatic], [w].[Name], [w].[OwnerFullName], [w].[SynergyWithId]
FROM [Weapons] AS [w]
ORDER BY CASE
    WHEN (CASE
        WHEN [w].[Name] = N'Marcus'' Lancer' THEN 0
        WHEN [w].[Name] > N'Marcus'' Lancer' THEN 1
        WHEN [w].[Name] < N'Marcus'' Lancer' THEN -1
    END = 0) AND CASE
        WHEN [w].[Name] = N'Marcus'' Lancer' THEN 0
        WHEN [w].[Name] > N'Marcus'' Lancer' THEN 1
        WHEN [w].[Name] < N'Marcus'' Lancer' THEN -1
    END IS NOT NULL THEN CAST(1 AS bit)
    ELSE CAST(0 AS bit)
END, [w].[Id]");

Для неопределенного спаравочника Хотелось бы что типа такого

    switch TableNumber
            {
                1=> null,
                2=> бд.Спр_Поставщики.Where(поставщик=> поставщик.Id==SprId).DefaultIfEmpty()
select new
                     {
                        Наименование
                        
                     },
                3=> бд.Спр_Покупатели.Where(покупатель=> поставщик.Id==SprId).DefaultIfEmpty()
select new
                     {
                        Наименование
                        
                     },
                _=>null
            }

То есть такое генерилось, но вызывалось как
ПолеНеопределенногоСправочника.Наименование
Кроме того можно применять утиную типизацию для классов с одинаковыми именами полей