Интерфейс IService для вызова сервисов. Один прокси на метод или глобальный прокси уровня класса

Я использую службы WCF из приложения Silverlight (MVVM) и телефона Windows. У меня есть класс службы (автоматически сгенерированный), и один IServiceRepository выглядит следующим образом

public interface IServiceRepository
{
  event EventHandler<SomeEventArgs> GetDataCompleted;
  void Data GetData();
  // 10 more methods for fetching different data.
}

Мой SerViceRepository выглядит следующим образом

 public class ServiceRepository : IServiceRepository
    {
       public event EventHandler<SomeEventArgs> GetDataCompleted;

       public void Data GetData()
       {
          var proxy = new ActualServiceRefClient();
          proxy.GetDataCompleted += PrivateGetDataCompleted;
          proy.GetDatAsync();
       }

       private void PrivateGetDataCompleted(object s, SomeEventArgs e)
       {
         // Error check and all
         if(GetDataCompleted != null)
            GetDataCompleted(this, new SomeEventArgs(...));
       }
    }

Я вызываю эти методы из моих ViewModels. Теперь мои вопросы...

  1. Прямо сейчас я создаю прокси-класс и присоединяю к нему обработчик событий в каждом методе. Должен ли я сделать это в конструкторе ServiceRepository? Как я уже сказал, у меня есть от 10 до 12 сервисных методов для вызова.
  2. Должен ли я отменить регистрацию обработчика событий в завершенном методе?

mvvm c# event-handling mvvm-light windows-phone-7
person Tanmoy    schedule 04.11.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

  1. Я не уверен, что имеет значение, куда он идет. Если у вас есть только один фактический метод службы, который вы вызываете, имеет смысл поместить проводку событий в конструктор. Если для каждого из 10 методов данных в вашем репозитории есть один фактический метод службы, то имеет смысл подключить их к каждому из 10–12 отдельных методов.

  2. По-разному. Если вы храните экземпляр репозитория служб, выполняя несколько вызовов к нему, вам следует либо переместить проводку событий в конструктор, либо убедиться, что вы не переустанавливаете обработчик событий при каждом вызове. В качестве альтернативы вы МОЖЕТЕ отменить регистрацию, как вы сказали, но я думаю, что лучше зарегистрировать эти обработчики событий один раз на весь срок службы объекта. Если вы просто создаете новый экземпляр своего репозитория служб для каждой банки, нет необходимости отменять регистрацию обработчиков событий.

Надеюсь это поможет!

person Adam Barney    schedule 08.11.2010
comment
проблема в том, что у меня есть около 15 сервисных методов и 15 событий для регистрации. Каждая из моих моделей представления вызывает два или три метода обслуживания. Обычно это не проблема, если я оставляю обработчики событий на всю жизнь, но, как и в Windows Phone 7, максимальная пиковая память составляет 90 МБ, мы беспокоимся о памяти. - person Tanmoy; 09.11.2010
comment
Я думаю, что буду создавать экземпляр репозитория службы каждый раз, когда это необходимо, и подключать обработчики событий в каждом отдельном методе. Пусть сервисный репозиторий выйдет из области видимости, и сборщик мусора вернет память. - person Adam Barney; 09.11.2010
comment
Спасибо. Я предполагаю, что это способ, предложенный с MVC, а также с использованием контекста данных LINQ. Хотя ссылку не нашел - person Tanmoy; 13.11.2010