Подскажите наиболее простое решение для реализации events в Remoting

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

MD>Подскажите наиболее простое решение для реализации events в Remoting

А какие у вас есть сложные решения? По-моему, их нет так уж и много: простенький прокси-класс, производный от MBR, интерфейс которого известен на сервере. Метод прокси регистрируется как обработчик события на сервере. Сделать у прокси еще одно событие, на которое подписывается клиент и которое возбуждается при вызове обработчика на серверное событие. Может че-нить с дженериками помутить, чтоб не плодить прокси-классы... Ф-у-ух
Да и вообще, лучше event'ы не использовать, ну тока если уж очень надо и в локалке, а так лучше не стоит.

H>А какие у вас есть сложные решения? По-моему, их нет так уж и много: простенький прокси-класс, производный от MBR, интерфейс которого известен на сервере. Метод прокси регистрируется как обработчик события на сервере. Сделать у прокси еще одно событие, на которое подписывается клиент и которое возбуждается при вызове обработчика на серверное событие. Может че-нить с дженериками помутить, чтоб не плодить прокси-классы... Ф-у-ух
H>Да и вообще, лучше event'ы не использовать, ну тока если уж очень надо и в локалке, а так лучше не стоит.

К чему такие трудности? В 1,1 вроде, работало без прокси класса. А можно какойнить примерчик?

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

H>>А какие у вас есть сложные решения? По-моему, их нет так уж и много: простенький прокси-класс, производный от MBR, интерфейс которого известен на сервере. Метод прокси регистрируется как обработчик события на сервере. Сделать у прокси еще одно событие, на которое подписывается клиент и которое возбуждается при вызове обработчика на серверное событие. Может че-нить с дженериками помутить, чтоб не плодить прокси-классы... Ф-у-ух
H>>Да и вообще, лучше event'ы не использовать, ну тока если уж очень надо и в локалке, а так лучше не стоит.

MD>К чему такие трудности? В 1,1 вроде, работало без прокси класса.
В чем трудность-то? В создании дополнительного класса? А вы предпочитаете класс, который предназначен сугубо для использования на клиенте, сделать производным от MBR и отправить его на сервер? Может это и проще, но уж, ИМХО, коряво.

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

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

MD>>Подскажите наиболее простое решение для реализации events в Remoting

H>А какие у вас есть сложные решения? По-моему, их нет так уж и много: простенький прокси-класс, производный от MBR, интерфейс которого известен на сервере. Метод прокси регистрируется как обработчик события на сервере. Сделать у прокси еще одно событие, на которое подписывается клиент и которое возбуждается при вызове обработчика на серверное событие. Может че-нить с дженериками помутить, чтоб не плодить прокси-классы... Ф-у-ух

не интерфейс, а реализация

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

H>>А какие у вас есть сложные решения? По-моему, их нет так уж и много: простенький прокси-класс, производный от MBR, интерфейс которого известен на сервере. Метод прокси регистрируется как обработчик события на сервере. Сделать у прокси еще одно событие, на которое подписывается клиент и которое возбуждается при вызове обработчика на серверное событие. Может че-нить с дженериками помутить, чтоб не плодить прокси-классы... Ф-у-ух

S>не интерфейс, а реализация

А зачем серверу реализация?

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

S>>не интерфейс, а реализация

H>А зачем серверу реализация?

скучает он без нее

http://support.microsoft.com/default.aspx?scid=kb;en-us;312114

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

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

S>>>не интерфейс, а реализация

H>>А зачем серверу реализация?

S>скучает он без нее

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

/// сборка находится на сервере и клиенте
interface IProxy
{
   void CallbackFunc();
}


/// сборка только на клиенте
class Proxy : MarshalByRefObject, IProxy
{
   public event SomeDelegate ServerEvent;
   ///
   
   void IProxy.CallbackFunc()
   {
      if(ServerEvent != null)
      {
           ServerEvent();
      }
   }
}


class Client
{
    void RegisterHandler()
    {
       IProxy proxy = new Proxy();
       proxy.ServerEvent += ..... bla-bla
        _serverObj.RegisterHandler(proxy);
    }
}


class Server : MBR
{
   public void RegisterHandler(IProxy proxy)
   {
        ///
   }
}

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

H>Т.е. вы хотите сказать, что если я на сервер выложу сборку только с определением интерфейса, например, IProxy, и буду передавать на сервер объект данного класса через параметр типа IProxy, то ничего работать не будет?

так точно

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

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

H>>Т.е. вы хотите сказать, что если я на сервер выложу сборку только с определением интерфейса, например, IProxy, и буду передавать на сервер объект данного класса через параметр типа IProxy, то ничего работать не будет?

S>так точно

Вы сами-то пробовали когда-нить использовать события на сервере? Мне кажется нет

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

H>>>Т.е. вы хотите сказать, что если я на сервер выложу сборку только с определением интерфейса, например, IProxy, и буду передавать на сервер объект данного класса через параметр типа IProxy, то ничего работать не будет?

S>>так точно

H>Вы сами-то пробовали когда-нить использовать события на сервере? Мне кажется нет

шьёрт побьери, ты прав ... если передавать в качестве параметра, то работает ...

ЗЫ: события использовал, тока подписывался непосредственно к событиям сервера.