IService интерфейс за извикване на услуги. Един прокси на метод или глобален прокси на ниво клас

Консумирам WCF услуги от приложение Silverlight (MVVM) и Windows Phone. Имам клас на услугата (автоматично генериран) и едно 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. Зависи. Ако държите екземпляр на Service Repository наоколо, като правите няколко извиквания към него, тогава трябва или да преместите окабеляването на събитието към конструктора, или да се уверите, че не свързвате повторно манипулатора на събития при всяко повикване. Като алтернатива МОЖЕТЕ да отмените регистрацията, както казахте, но мисля, че е най-добре да регистрирате тези манипулатори на събития веднъж за целия живот на обекта. Ако просто създавате ново копие на вашето хранилище на услуги за всяка кутия, няма нужда да дерегистрирате манипулаторите на събития.

Надявам се това да помогне!

person Adam Barney    schedule 08.11.2010
comment
проблемът е, че имам около 15 метода за обслужване и следователно 15 събития, за които да се регистрирам. Всеки от моите изгледни модели извиква два или три сервизни метода. Обикновено не е проблем, ако оставя манипулаторите на събития за целия живот, но тъй като в Windows phone 7 максималната пикова памет е 90 Mb, ние сме загрижени за паметта - person Tanmoy; 09.11.2010
comment
Мисля, че бих инстанцирал хранилището на услугата всеки път, когато е необходимо, и бих свързал манипулаторите на събития във всеки отделен метод. Оставете хранилището на услугата да излезе извън обхвата и събирачът на боклук ще си върне паметта. - person Adam Barney; 09.11.2010
comment
Благодаря. Предполагам, че това е начинът, предложен с MVC и използване на LINQ datacontext също. Въпреки че не можах да намеря връзката - person Tanmoy; 13.11.2010