Сделать интерфейсы для удобной работы с Вложениями Диадок about diadocsdk-csharp

[SLenik]

Уважаемые разработчики. Так что Вы по этому поводу думаете?

[trurl123]

Я не разработчик Diadoc SDK, но разрабатываю интеграционные сервисы для Диадока. На самом деле есть такая проблема и ее хотелось бы решить.

[asvyazin]

А откуда вообще эта задача добавлять произвольные вложения берется? Мне кажется, в каждом конкретном месте всегда известно, что именно ты добавляешь, и необходимости в этом методе нет. Я только один пример вижу и то сомнительный - в тестах желание отправить все возможные типы документов, например... А еще?

[trurl123]

Например, у тебя есть отдельный код, который создает вложения и отдельный код, который ставит подписи. Чтобы поставить подписи тебе нужно делать switch по типу вложения, либо через рефлексию обращаться к свойствам. Или нужно получить список номеров документов у полуформализованных.
Вложения имеют общие свойства и эти свойства по логике одинаковы. Поэтому есть смысл работать со списком вложений.

[einfoman]

@trurl123, А как быть с тем, что некоторые типы (например, полуформализованные) позволяют дополнительную информацию передавать?

[trurl123]

@einfoman Для полуформализованных тоже можно отдельный интерфейс завести, который будет наследоваться от базового интерфейса для документа.

[SLenik]

А откуда вообще эта задача добавлять произвольные вложения берется? Мне кажется, в каждом конкретном месте всегда известно, что именно ты добавляешь...

@asvyazin Кроме того случая, когда логика отправки документов отделена от логики их обработки.

Система ЭДО, которую я поддерживаю, является мультипровайдерной и, как следствие, имеет несколько слоёв. В частности, у нас логика обработки ЭД, например, создание подписи, генерации парных служебных документов: титула покупателя для подписи им титула продавца, а также создание ИоП или УоУ, - всё это мы делаем самостоятельно, дабы не зависеть от конкретной реализации этих функций у провайдера; и этот код вынесен на отдельный слой системы.
А работа с непосредственно с API провайдера находится уровнем ниже и строится так, чтобы соответствующие классы были лишь простейшими транслятором между сущностями и операциями нашей системы и сущностями и операциями конкретного провайдера.

Именно поэтому мы и хотим избавиться от копипасты при отправке: функция отправки сообщения в адаптере для провайдера Диадок у нас получает аналог Вашего типа MessageToPost: адрес отправителя + адрес получателя + список объектов на отправку (ближе всего это к помеси Entity + SignedContent) – и по факту всё, что ей надо сделать это вызвать PostMessage. Вот только сейчас для этого приходится использовать монструозный код из примера в первом сообщении.

ЗЫ. Кстати, пример с кодом подписи @trurl123 тоже очень показателен: представьте что для доступа к ЭЦП приходится использовать отдельный сервис наподобие КриптоПро DSS.

[SLenik]

@trurl123, А как быть с тем, что некоторые типы (например, полуформализованные) позволяют дополнительную информацию передавать?

@einfoman Для полуформализованных тоже можно отдельный интерфейс завести, который будет наследоваться от базового интерфейса для документа.

Действительно, вариантов масса. Например для начала сгруппировать дополнительную информацию по её типу и сделать на каждую свой интерфейс:

• IAttachmentWithComment - если у объекта есть комментарий
• IAttachmentWithRelatedDocuments - если для объекта можно устанавливать связанные документы и т.п.

А как все такие интерфейсы будут - собрать из них уже составные типа
INonformalizedAttachment : IAttachmentWithComment, IAttachmentWithRelatedDocuments
в которые добавить свойства, которые относятся именно к неформализованным документам и ни к каким либо ещё.

[SLenik]

Спят усталые игрушки, книжки спят... =)

[atytsky]

Оставлю ссылки здесь и закрою тикет:

• diadoc/diadocapi-docs#269

• #218