Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>Собственно классическая задача у нас есть некая информация ( например в простейшем случае это byte[], чуть немного более сложный — объект с полями )
А>>и эту информацию нужно куда-то передать, возможно получив также в ответ некую информацию.

S>Как всегда — начинаем с языка/фреймворка, затем описываем задачу на наборе типовых сценариев и под конец ищем готовые решения. Пока все три пункта не сделаны, обсуждать что-либо бессмысленно, т.к. под такие критерии подходит что угодно.

Фреймворк можно уточнить .net, хотя не понятно чем аналогичное решение будет отличаться от java, c++ &mac||Linux.

Типовой сценарий — есть данные в каком-то виде, как я писал — это может быть строка, может массив байт, может объект, может стрим что еще можно нафантазировать ?
Есть что-то что умеет эти данные обрабатывать, это может быть сервер внешний ( rest, wcf, tcp/socket, http, smtp, в общем практически любая известная технология передачи данных ), это может быть даже СOM-объект или что-то иное что может принимать данные и что-то с ними делать.

Когда будет конкретный сценарий тогда и напишем реализацию например передача массива byte[] по stmp — это уже конкретика.
А наша задача — это не реализовать все все протоколы а только создать общий интерфейс, чтобы в перспективе в духе DI — можно было подменить протокол/тип данных ( примерно как это делается в wcf взял и одной настройкой http сменил на tcp ).

Т.е. интерфейс должен охватывать максимальное количество известных протоколов, если например из 100 известных протоколов 2 маргинальных портят всю малину , то можно от них отказаться



S>Например, для дотнета:
S>* wcf (если речь о передаче по сети/между процессами)
S>* stream (если нужен интерфейс для работы с потоком данных, в том числе и с устройств)
S>* любая из библиотек сериализации (тот же protobuf)
S>* события/IObservable (если речь о событиях в рамках процесса).

S>Выбирайте