Как лучше динамически генерировать модели из C# в 1С?

Question

[oldhowl]

У нас разрастается проект и мы переделываем архитектуру.
Продаем цифровые продукты.
У нас есть генерация этих продуктов в PDF где все завязано на и есть 1С куда нужно заносить данные о продаже с этими же самыми полями. Я не спец по 1С, мне предоставили SOAP endpoint и документацию, где в запросах фигурируют xml модели на кириллице. Сначала было все ничего, мы из агрегата продукта вручную составляли модели через XDocument, генерировали xml и отправляли на endpoint, так же из этого агрегата составляли модель для PDF генерации подменой слов в шаблоне. Теперь хотим убить двух зайцев, как то динамически генерировать и те и те модели. Если с PDF частью все просто, то больше всего убивает 1С с кириллицей.
В связи с чем возникло несклько идей:

1. Записывать оплаченные ордеры в базу и просто передавать в 1C айдишники оплаченных ордеров, а 1С на своей стороне будет брать оплаченные ордеры из базы мэппить модели.
Плюсы:
- в 1с все инкапсулировано и от нас скрыт ад кириллицы
- разработка быстрее, мы просто кладем в базу и дергаем 1С
Минусы:
- Не динамически. На каждый продукт в 1С придется вручную прописывать логику мэппинга.

2. Сделать модульность, на каждый продукт создавать библиотеку класса с мэппингом для 1С и обрамить интерфейсом.
Плюсы:
- На каждый продукт в 1С НЕ придется вручную прописывать логику мэппинга.
Минусы
- эта ответственность перекладывается на нас и опять же нет динамики

3. Прописывать конфигурацию для каждого продукта с мэппингом полей

{
    "PayDate" : "ДатаОплаты",
    "RentPrice" : "СтоимостьАренды"
    ...
}

И динамически генерировать XDocument подставляя поля из конфигурации.
Плюсы:
- Описывается конфигом на продукт, не надо менять код
Минусы:
- Сложная логика (рефлексия, множество ветвлений)
- Могут появиться вложенные модели
- Тяжело поддерживать

Есть какие то идеи?

Comments

[Константин Нагибович]

Это все из-за кириллицы?

[oldhowl]

Константин Нагибович, да

Answer 1

[Александр Кузнецов]

Если честно, не вижу проблемы использовать кириллицу в качестве классов в C#. Это работает, хоть и выглядит не очень (ну и красота - субъективное понятие).

Если же порекомендовать один их вариантов - я бы выбрал бы третий вариант. Почему - по моему опыту, в 1C пускают сложно и все телодвижения там - весьма затратные (оплата специалиста, если его нет в штате, время реагирования на таск в целом, отладка взаимодействия - у вас может быть рассинхрон по времени и проблемы совместного запуска интеграционных тестов и т.д.).

Третий вариант хорош тем, что вы можете сделать как ручной маппер, так и маппинг по структурированному документу (json, xml и т.п.). Мне не кажется, что он будет особенно сложным, даже при вложенности моделей.
Такой вариант позволит куда оперативнее реагировать на возможные нюансы, и, что тоже не мало важно, правила Transform-части можно сделать и в виде странички, где их можно проставлять обычному сотруднику, без привлечения программиста.

Конечно, все что я написал построено на моих догадках и, возможно, всего этого и не требуется. Но, данный вариант дает наибольшую свободу для вас в будущем, как мне кажется.

p.s.
Опять же, вариант с настройкой на вашей стороне может позволить вам использовать библиотеки вида Automapper, к примеру - но, там, скорее всего, только через кодогенерацию.

Comments

[oldhowl]

да, скорее всего придется через третий вариант.
Есть еще некрасивое, но очень простое решение, получить xml и через string.Replace() заменить всю латиницу на кириллицу через конфигурацию из третьего варианта, но мой технический долг не дает мне покоя :)

Answer 2

[Игорь]

А ещё можно заставить 1С-ников переделать ендпоинты на латиницу и не клепать костыли. потому что скорее всего они самописные, а не штатные