Связь между программами в .NET

Question

Связь между программами в .NET

2

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

Я рассматривал 2 метода:

создать класс со всеми подробностями. Отправьте его на уровень связи. Этот сериализует его, отправляет, а другая сторона десериализует его обратно в класс и обрабатывает его далее.
Создайте хэш-таблицу (ключ/значение). Поместите в него все данные. Отправьте его игроку связи и т.д. И т.д.

Итак, это сводится к хеш-таблице и классу.

Если я думаю, что "слабо связан", я выступаю за хэш-таблицу. Легко обновить один модуль, включить новые дополнительные параметры в hastable, не обновляя другую сторону.

Затем снова с классом я получаю проверку типа компиляции, а не время выполнения.

Кто-нибудь занимался этим раньше и имеет предложения об этом?

Спасибо!

изменить: Я получил баллы за ответ, который был наиболее важен для моего первоначального вопроса, хотя это не тот, который был поддержан наиболее

Toad 16 авг. 2009, в 14:16

Источник

0

Лично я бы пошел с отдельным классом, но мой главный комментарий здесь заключается в том, что вы должны исправить использование «сериализации» и «десериализации», вы их переключили, сериализация берет объект и производит данные из него, десериализация создает объект из данные.
Lasse Vågsæther Karlsen 16 авг. 2009, в 11:49
0

ты прав ... мой плохой; ^)
Toad 16 авг. 2009, в 12:06

Теги:

c#

software-design

.net

ipc

5 ответов

4

Похоже, вы просто хотите включить в свою систему IPC (Inter-Process Communication).

Лучший способ выполнить это в .NET(начиная с версии 3.0) - с Windows Communication Foundation (WCF) - разработана общая структура Microsoft для связи между программами различными способами (транспортом) на общей основе.

Хотя я подозреваю, что вы, вероятно, захотите использовать именованные каналы в целях повышения эффективности и надежности, существует целый ряд других транспортных средств, таких как TCP и HTTP (см. в этой статье MSDN), не говоря уже о различных форматах сериализации от двоичного до XML в JSON.

Noldorin 16 авг. 2009, в 09:05

0

Вы могли бы быть правы, что я в конечном итоге с этой технологией. Однако, прежде чем использовать готовое решение, я сначала хочу создать фреймворк самостоятельно, хотя бы для лучшего понимания его. Мой способ транспортировки, вероятно, будет tcp-ip / http с использованием json (именованные каналы не пересекают границы машины, верно?)
Toad 16 авг. 2009, в 12:05
0

@reinier: Достаточно справедливо. В этом случае я бы порекомендовал использовать какой-нибудь простой формат сериализации (встроенные двоичные / XML-форматеры или буферы протокола) и передавать эти данные по TCP. Скоро вы поймете, почему лучше использовать существующий фреймворк. :) Но да, это может быть полезно понять. Кроме того, именованные каналы могут существовать между различными компьютерами в сети, но не через Интернет; посмотрите это, например: stackoverflow.com/questions/244367/…
Noldorin 16 авг. 2009, в 13:30
1

ты уверен насчет названных труб? в справочнике msdn говорится, что он предназначен для межпроцессного взаимодействия с использованием общей памяти. Как это можно сделать на отдельных машинах? msdn.microsoft.com/en-us/library/aa365780(VS.85).aspx
Toad 16 авг. 2009, в 17:46
0

Да. Смотрите вопрос, с которым я связан. Вам просто нужно использовать имя UNC для подключения по сети.
Noldorin 16 авг. 2009, в 18:43
0

на вопрос, на который вы ссылаетесь, есть ответ (внизу) со ссылкой, в которой прямо сказано, что это невозможно; ^)
Toad 17 авг. 2009, в 12:46
0

@reiner: Ах, возможно , WCF не поддерживает для него ... Названы труб в целом, однако, не поддерживает между передачей данных по сети.
Noldorin 17 авг. 2009, в 13:35

Показать ещё 4 комментария

0

Что случилось со встроенной поддержкой Remoting?

http://msdn.microsoft.com/en-us/library/aa185916.aspx

Он работает на TCP/IP или IPC, если вы хотите. Это быстрее, чем WCF, и довольно прозрачно для вашего кода.

shimpossible 16 авг. 2009, в 10:07

0

если в какой-то момент я захочу добавить связь с другими системами / языками, мне нужно углубиться в глубину, чтобы понять, как все это работает внутри. Если я сам что-то спроектирую, то, возможно, я снова сделаю много работы, но, по крайней мере, научусь этому и лучше пойму, как и почему это работает, и почему были приняты определенные решения. Во всяком случае, ... ваш ответ на самом деле не отвечает на мой вопрос о хэш-таблицы против класса
Toad 16 авг. 2009, в 12:25
1

WCF является преемником удаленного взаимодействия в .NET 2.0, и, помимо того, что он является более полной и современной средой, я не верю, что он работает медленнее. Я хотел бы увидеть некоторые доказательства этого.
Noldorin 16 авг. 2009, в 13:31

0

Вы можете использовать Sockets, Remoting или WCF, у eash есть плюсы и минусы.

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

Ahmed Said 16 авг. 2009, в 09:28

0

спасибо за ввод, но ваш ответ на самом деле не отвечает на мой вопрос о hashtable vs class
Toad 16 авг. 2009, в 12:26

-1

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

Просто сложно правильно использовать WCF, в том числе правильно обрабатывать ошибки на каналах, сохраняя при этом хорошую производительность (мы отказались от высокой производительности с помощью wcf на ранней стадии).

Для аутентифицированных клиентских сценариев мы переключились на http rest (без wcf) и выполнили полезную нагрузку json/protobuf.

Для высокоскоростных сценариев, не прошедших проверку подлинности (или, по крайней мере, не связанных с Kerberos сценариев), мы теперь используем zeromq и protobuf.

mgoetzke 09 фев. 2011, в 08:26

Ещё вопросы

Лично я бы пошел с отдельным классом, но мой главный комментарий здесь заключается в том, что вы должны исправить использование «сериализации» и «десериализации», вы их переключили, сериализация берет объект и производит данные из него, десериализация создает объект из данные.
Вы могли бы быть правы, что я в конечном итоге с этой технологией. Однако, прежде чем использовать готовое решение, я сначала хочу создать фреймворк самостоятельно, хотя бы для лучшего понимания его. Мой способ транспортировки, вероятно, будет tcp-ip / http с использованием json (именованные каналы не пересекают границы машины, верно?)
@reinier: Достаточно справедливо. В этом случае я бы порекомендовал использовать какой-нибудь простой формат сериализации (встроенные двоичные / XML-форматеры или буферы протокола) и передавать эти данные по TCP. Скоро вы поймете, почему лучше использовать существующий фреймворк. :) Но да, это может быть полезно понять. Кроме того, именованные каналы могут существовать между различными компьютерами в сети, но не через Интернет; посмотрите это, например: stackoverflow.com/questions/244367/…
ты уверен насчет названных труб? в справочнике msdn говорится, что он предназначен для межпроцессного взаимодействия с использованием общей памяти. Как это можно сделать на отдельных машинах? msdn.microsoft.com/en-us/library/aa365780(VS.85).aspx
Да. Смотрите вопрос, с которым я связан. Вам просто нужно использовать имя UNC для подключения по сети.
на вопрос, на который вы ссылаетесь, есть ответ (внизу) со ссылкой, в которой прямо сказано, что это невозможно; ^)
@reiner: Ах, возможно , WCF не поддерживает для него ... Названы труб в целом, однако, не поддерживает между передачей данных по сети.
если в какой-то момент я захочу добавить связь с другими системами / языками, мне нужно углубиться в глубину, чтобы понять, как все это работает внутри. Если я сам что-то спроектирую, то, возможно, я снова сделаю много работы, но, по крайней мере, научусь этому и лучше пойму, как и почему это работает, и почему были приняты определенные решения. Во всяком случае, ... ваш ответ на самом деле не отвечает на мой вопрос о хэш-таблицы против класса
WCF является преемником удаленного взаимодействия в .NET 2.0, и, помимо того, что он является более полной и современной средой, я не верю, что он работает медленнее. Я хотел бы увидеть некоторые доказательства этого.
спасибо за ввод, но ваш ответ на самом деле не отвечает на мой вопрос о hashtable vs class

djna · Accepted Answer · 2009-08-16T10-52-00.000Z

Как правило, этот вопрос возникает в дизайне распределенных систем. Он отображается в веб-службе (WSDL, определяющий параметры и типы возврата). Системы обмена сообщениями, в которых форматы сообщений могут быть XML или каким-либо другим четко определенным форматом. Проблема управления связью клиента и сервера остается во всех случаях.

Что происходит с вашей хэш-таблицей? Предположим, что ваш запрос содержит "NAME" и "PHONE-NUMBER", и вдруг вы осознаете, что вам нужно различать "LANDLINE-NUMBER" и "CELL-NUMBER". Если вы просто измените записи хэш-таблицы, чтобы использовать новые значения, тогда ваш сервер должен измениться в одно и то же время. Предположим, на данный момент у вас есть не только один клиент и один сервер, но, возможно, имеет дело с каким-то обменным или брокерским системами, многие клиенты реализованы многими командами, многие серверы реализованы многими командами. Просить всех из них перейти на новый формат сообщения в то же время - это довольно серьезная задача.

Следовательно, мы стремимся искать обратно-доступные решения, такие как добавление, мы сохраняем "PHONE-NUMBER" и добавляем новые поля. Теперь сервер переносит сообщения, содержащие старый или новый формат.

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

Я бы выполнил следующий процесс:

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

2). Даже если вы контролируете, как легко ваша среда для сериализации поддерживает управление версиями. Скорее всего, с ним будет работать более сложный интерфейс с сериализованным классом, и вы сможете получить четкое представление о том, что он предпримет, чтобы внести изменения в интерфейс.

Вы правы, что нужно иметь дело с какой-то версионностью. Мне кажется, что для этого проще использовать хеш-таблицы. Просто имейте одно дополнительное поле «версия», и принимающая сторона знает, какие параметры они могут ожидать.