Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[52.14.218.79] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
У меня будет слюжба (сервис) и приложение, которое должно служить интерфейсом этой службы. Служба в частности обращается к базе данных. Вопрос. Какие сейчас есть современные средства обмена данными между службой и приложением НА ОДНОМ КОМПЕ? Раньше я тупо использовал сокет на 127.0.0.1 для обмена. Может что поинтереснее есть? И чтобы данные легко было передавать и менять.
|
Сообщ.
#2
,
|
|
|
Средства сейчас остались теме же... Если очень уж хочется извратиться -- можешь Remouting поюзать...
|
Сообщ.
#3
,
|
|
|
Цитата Jupiter @ Может что поинтереснее есть? 1. System.Runtime.Remoting 2. Windows Communication Foundation Цитата _hunter @ - почему извратиться? Отличное средство межпроцессного взаимодействия, + получаешь масштабируемость. Если очень уж хочется извратиться |
Сообщ.
#4
,
|
|
|
COM, Web Service, named pipe, File.Write + FileSystemWatcher, MSMQ...
|
Сообщ.
#5
,
|
|
|
Цитата J0ker @ COM, Web Service, named pipe, File.Write + FileSystemWatcher, MSMQ... Но счет named pipe. Это ведь технология, основанная на WinAPI... Есть ли в .NET свежая оболочка для этой идеи? |
Сообщ.
#6
,
|
|
|
Встречный вопрос, а чем не подходит Remoting?
|
Сообщ.
#7
,
|
|
|
Я не говорил, что он мне не подходит. Более того, скорее всего я на нем-то и остановлюсь. Но мне интересно про named pipes.
|
Сообщ.
#8
,
|
|
|
Цитата Jupiter @ named pipes. кстати новая штука в .NET в 2.0 точно не было. А если Remoting то там есть прикольный протокол как раз для локальной машины - IPC |
Сообщ.
#9
,
|
|
|
Цитата Jupiter @ - если юзаешь 3.0, то для WCF если мне не изменяет память - один из видов байндинга Но мне интересно про named pipes. |
Сообщ.
#10
,
|
|
|
Цитата juice @ Было зато в windows 3.1, так что условно новая кстати новая штука в .NET в 2.0 точно не было. |
Сообщ.
#11
,
|
|
|
Цитата ANDLL @ Было зато в windows 3.1 То что именнованые каналы были я знаю, даже в Жабе была их поддержка, а я как раз про .NET. Я думаю их ввели в связи с добавлением библиотек по созданию аддинов. Они активно юзают их в своей реализации обеспечивая взаимодействия между доменом хоста и доменами куда загружаются плагины. |
Сообщ.
#12
,
|
|
|
Понимаю, что глупый вопрос, но все же... Вот я делаю ремоутинг, как советовал juice на канале IPC. Во всех примерах фигурируют три проекта: кроме клиента и сервера еще и сам класс, который будет создаваться удаленно. Где-то даже делают это не класс, а интерфейс. Мне не надо, чтобы была отдельная DLL для реализации класса. Хорошо, пусть это будет не класс, а интерфайс - какой-нибудь ICallableObject. Ну и где мне его описывать? Я делал в принципе как - описывал интерфайс одинаково дважды: в проекте сервера и в проекте клиента. И оно работало. Но не буду же я так делать всегда, хочется один раз его описать. То есть должен ли я описать интерфейс в одтельном файле .cs и включить этот файл в оба проетка, или держать описание интерфейса, скажем, в проете сервера, а в проекте клиента сделать референс?
|
Сообщ.
#13
,
|
|
|
Цитата Jupiter @ Ну и где мне его описывать? Создается отдельный проект Сlass Library с твоим интерфейссом. Ты ссылаешься на него в проекте сервера (реализуешь интерфейс) и цепляешь его к клиенту, что бы иметь возможность обращаться к серверу. Иметь его как сs в проекте сервера не разумно, клиенту не нужна сборка с реализацией сервера. + к этому там где сборка с интерфейссом, можно объявлять собственные типы, которые могут пересекать границы домена между клиентом и сервером. |
Сообщ.
#14
,
|
|
|
Цитата juice @ Создается отдельный проект Сlass Library с твоим интерфейссом ... + к этому там ... можно объявлять собственные типы, которые могут пересекать границы домена между клиентом и сервером. И этот проект все-таки будет компилироваться в DLL? (извиняюсь за глупые вопросы, но я новичок в .net) |
Сообщ.
#15
,
|
|
|
Цитата Jupiter @ этот проект все-таки будет компилироваться в DLL? - да |