Шаблон проектирования доступа к данным

Question

В настоящее время я создаю приложение для Windows 8 Store, которое требует от меня нескольких вызовов веб-сервисов. Вызовы возвращают строку json, которую я десериализую в объекты. Я использую шаблон проектирования MVVM с помощью Caliburn.Micro для WinRT.

Первоначально, чтобы получить данные от вызовов веб-службы в каждой из моих моделей просмотра, я создал класс DataStore, который объявил статический экземпляр сам по себе. У этого класса были свойства, соответствующие всем моим моделям. Когда требуется вызов веб-службы, я вызвал метод статического класса в «APIData», который читал в словаре параметров, сериализовал эти параметры в JSON, сделал вызов API и вернул результат JSON в класс DataStore. В этот момент JSON был десериализован и использовался для обновления свойств DataStore. В каждой из моих моделей ViewModels я ссылался на то, какое свойство DataStore необходимо для datacontext этой виртуальной машины.

В результате появился повторяющийся код и очень грязный класс DataStore.

Мой вопрос заключается в том, что было бы хорошим шаблоном проектирования для использования, когда json, возвращаемый из вызовов webservice, должен использоваться для заполнения моделей?

Answer 1

Похоже, что ваша первоначальная попытка сломала «single responsibility principle», и это привело к очень грязному классу DataStore.

Моей реализацией операций с данными в режиме просмотра является сохранение коллекции классов ViewModelPopulator. Каждая заполненная viewmodel службы содержит ссылку на viewmodelpopulator, который несет ответственность за гидратацию свойств viewmodels.

Для содействия повторного использования кода, возможно, что один ViewModel может быть заполнен различным populators (например, «CarCollectionViewModel» быть заселены либо «HondaCollectionViewModelPopulator» или «KiaCollectionViewModelPopulator»), следовательно, ссылками на самом деле, чтобы IViewModelPopulator<T> где T - это viewmodel для заполнения.

Это приводит к ослаблению связи между режимами просмотра и уровнем доступа к данным. В вашем примере я бы разместил десериализацию Json (возможно, через некоторые вспомогательные методы) в классах viewmodelpopulator.

Кроме того, это позволяет декларативно вводить насекомые в режим просмотра из слоя пользовательского интерфейса во время разработки (в соответствии с приведенным ниже примером) или назначать их в кодовом коде во время выполнения.

<Page.DataContext> 
    <VM:SearchPageViewModel> 
     <VM:SearchPageViewModel.ViewModelPopulator> 
      <VMP:SearchPageViewModelPopulator /> 
     </VM:SearchPageViewModel.ViewModelPopulator> 
    </VM:SearchPageViewModel> 
</Page.DataContext>