Взаимодействие моего приложения с моей службой , (на одном компе)

У меня будет слюжба (сервис) и приложение, которое должно служить интерфейсом этой службы. Служба в частности обращается к базе данных. Вопрос. Какие сейчас есть современные средства обмена данными между службой и приложением НА ОДНОМ КОМПЕ? Раньше я тупо использовал сокет на 127.0.0.1 для обмена. Может что поинтереснее есть? И чтобы данные легко было передавать и менять.

Средства сейчас остались теме же... Если очень уж хочется извратиться -- можешь Remouting поюзать...

Цитата Jupiter @ 01.04.08, 09:19

Может что поинтереснее есть?

1. System.Runtime.Remoting
2. Windows Communication Foundation

Цитата _hunter @ 01.04.08, 09:29

Если очень уж хочется извратиться

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

COM, Web Service, named pipe, File.Write + FileSystemWatcher, MSMQ...

Цитата J0ker @ 01.04.08, 19:54

COM, Web Service, named pipe, File.Write + FileSystemWatcher, MSMQ...

Но счет named pipe. Это ведь технология, основанная на WinAPI... Есть ли в .NET свежая оболочка для этой идеи?

Встречный вопрос, а чем не подходит Remoting?

Я не говорил, что он мне не подходит. Более того, скорее всего я на нем-то и остановлюсь. Но мне интересно про named pipes.

Цитата Jupiter @ 03.04.08, 14:51

named pipes.

кстати новая штука в .NET в 2.0 точно не было.

А если Remoting то там есть прикольный протокол как раз для локальной машины - IPC

Цитата Jupiter @ 03.04.08, 14:51

Но мне интересно про named pipes.

- если юзаешь 3.0, то для WCF если мне не изменяет память - один из видов байндинга

Цитата juice @ 03.04.08, 14:58

кстати новая штука в .NET в 2.0 точно не было.

Было зато в windows 3.1, так что условно новая

Цитата ANDLL @ 04.04.08, 06:55

Было зато в windows 3.1

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

Понимаю, что глупый вопрос, но все же... Вот я делаю ремоутинг, как советовал juice на канале IPC. Во всех примерах фигурируют три проекта: кроме клиента и сервера еще и сам класс, который будет создаваться удаленно. Где-то даже делают это не класс, а интерфейс. Мне не надо, чтобы была отдельная DLL для реализации класса. Хорошо, пусть это будет не класс, а интерфайс - какой-нибудь ICallableObject. Ну и где мне его описывать? Я делал в принципе как - описывал интерфайс одинаково дважды: в проекте сервера и в проекте клиента. И оно работало. Но не буду же я так делать всегда, хочется один раз его описать. То есть должен ли я описать интерфейс в одтельном файле .cs и включить этот файл в оба проетка, или держать описание интерфейса, скажем, в проете сервера, а в проекте клиента сделать референс?

Цитата Jupiter @ 07.04.08, 14:44

Ну и где мне его описывать?

Создается отдельный проект Сlass Library с твоим интерфейссом. Ты ссылаешься на него в проекте сервера (реализуешь интерфейс) и цепляешь его к клиенту, что бы иметь возможность обращаться к серверу. Иметь его как сs в проекте сервера не разумно, клиенту не нужна сборка с реализацией сервера. + к этому там где сборка с интерфейссом, можно объявлять собственные типы, которые могут пересекать границы домена между клиентом и сервером.

Сообщение отредактировано: juice - 07.04.08, 15:02

Цитата juice @ 07.04.08, 15:00

Создается отдельный проект Сlass Library с твоим интерфейссом ... + к этому там ... можно объявлять собственные типы, которые могут пересекать границы домена между клиентом и сервером.

И этот проект все-таки будет компилироваться в DLL? (извиняюсь за глупые вопросы, но я новичок в .net)

Цитата Jupiter @ 08.04.08, 10:52

этот проект все-таки будет компилироваться в DLL?

- да