Архитектурный дизайн приложения Silverlight WP7, управляемого данными - PullRequest
8 голосов
/ 30 декабря 2010

У меня есть приложение Silverlight для Windows Phone 7, которое извлекает данные из общедоступного API.Я обнаруживаю, что делаю одно и то же снова и снова:

  • В пользовательском интерфейсе установите сообщение о загрузке или индикатор выполнения загрузки вместо того, чтобы содержимое было
  • .содержимое, которое может быть уже в памяти, кэшировано в изолированном файловом хранилище или требует HTTP-запроса
  • Если содержимое не может быть получено (без сетевого подключения и т. д.), отобразите сообщение об ошибке
  • Если содержимое получено, отобразите его в пользовательском интерфейсе
  • Сохраните содержимое в основной памяти для последующих запросов

Содержимое, отображаемое для пользователя, может быть взято непосредственно изисточник данных, такой как ObservableCollection, или это может быть запрос к источнику данных.

Я хотел бы выделить этот повторяющийся процесс в структуру, в которой в идеале необходимо указывать только следующее:

  • Где отображать содержимое в пользовательском интерфейсе
  • Элементы пользовательского интерфейса, отображаемые при загрузке, при сбое и при успехе
  • URI HTTP-запроса
  • Как разобрать ответ HTTP в структуру данных, которая будет храниться в памяти
  • Расположение файла в изолированном хранилище, если оно существует
  • Как проанализировать содержимое файлав структуру данных, которая будет храниться в памяти

Это может звучать как много, но две строки, три FrameworkElement с и два метода меньше, чем накладные расходы, которые у меня есть в настоящее время.

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

Мои вопросы:

Что-то подобное уже было реализовано?

Неужели мои мысли по поводу вышеприведенной темы в какой-то мере неверны?

Вот дизайн, который я 'Я думаю о:

Существует два компонента: представление и модель.

представлению дается FrameworkElement с для загрузки, сбоя и успеха.Также дается ссылка на соответствующую модель.Представление - это UserControl, которое помещается где-то в пользовательском интерфейсе.

Модель - это класс, которому присваивается URI для данных, метод анализа данных и, необязательно, имени файла и способразобрать файл.Он отвечает за извлечение данных и уведомление View при каждом изменении текущего состояния (загрузка / сбой / успех).Если данные, загруженные из сети, отличаются от кэша, данные сети имеют приоритет.Когда приложение закрывается или захороняется, модель записывает данные в кэш.

Как это звучит?

Ответы [ 2 ]

4 голосов
/ 02 января 2011

Я потратил некоторое время на то, чтобы внимательно прочитать ваши требования, и отметил некоторые мысли, которые можно предложить в качестве звучащей доски.

Во-первых, для повторяющихся задач с обычным поведением это, безусловно, подход к нему.Вы не одиноки в размышлениях об этой проблеме.

Люди, делающие кучу подобных вещей, возможно, создали подобные абстракции, однако, насколько мне известно, ни одна не была опубликована публично.

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

Я собираюсь предположить первое, но это не исключает возможности выпустить его как проект с открытым исходным кодом, который можно развивать дальше и / или разветвлять.

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

Я думаю, что в целом ваше мышление идет в правильном направлении.Читая некоторые ваши мысли высокого уровня, я подумал, что некоторые вещи можно упростить (что хорошо) и в то же время обеспечить привлекательный пользовательский интерфейс.

По вашим начальным точкам.

  • Вы можете просто предположить, что производительность передается через индикатор выполнения.
  • Сделайте это, если это важно для вас, но вы могли бы столкнуться с некоторой сложностью, связанной с различными требованиями к кешированию - изменением длительности или грязной обработкой.Возможно, этого достаточно, чтобы опираться на платформы, встроенные в кеширование URL-адресов (которые, как обнаружили некоторые люди, мешают им).
  • Обработка сетевого подключения, да, это повторяющееся и несколько запутанное.Идеальный кандидат для общего решения.
  • Обновление пользовательского интерфейса ... возможно, лучше просто возвращать данные и откладывать решения относительно представления и формата данных для ваших индивидуальных клиентов.
  • Содержимое в основной памяти -см. выше о кешировании.

О ваших потенциальных входах.

  • Где отобразить контент - см. выше данные и отложите выбор представления для клиента.
  • Я бы выбрал элемент пользовательского интерфейса для индикатора прогресса, опять же индикатор производительности.Что касается сообщения об ошибке, я хотел бы рассмотреть возможность реализации этого в событии Completed, которое вы публикуете.Затем с помощью параметров вы можете передать результат и отложить обработку клиенту, чтобы поместить этот результат в некоторый элемент управления представлением / журнал / что угодно.Это согласуется с шаблонами, используемыми .Net Framework.
  • URI - да, это передается.
  • Как выполнить синтаксический анализ - передача делегата для преобразования потока или строки в объектчей тип может быть определен клиентом, имеет смысл.
  • Loc of cache - вы можете пропустить это, если обобщите это, или жестко закодировать его путь.Это было бы более полезно для других, если передать (рассмотрим, если вы обрабатываете папки / создание).

О реализации.

  • Вы можете пойти с UserControl, еслиэто работает для вас, чтобы быть связанным этим предположением.Хотя было бы более гибким и, возможно, столь же простым / элегантным, отодвинуть презентацию на клиенте как для отображения данных, так и для сообщений о состоянии, а также для управления скрытием / отображением индикатора выполнения, как передано.
  • Возможно, выможет пойти дальше, если предположить, что сообщения о состоянии всегда будут отображаться в текстовом блоке (если они пройдены) и перенести эту служебную работу с каждого из ваших клиентов в ваш общий класс.
  • Я подозреваю, что вам не поможет соединениеФормат данных и представление все еще.
  • Обработка захоронения. Я бы рекомендовал провести здесь тестирование на платформах со встроенным кэшированием URL-адресов и посмотреть, сможете ли вы определить, подходят ли его длительности / грязные условия для ваших общих случаев.

Надеюсь, это даст вам некоторые соображения и определенную уверенность, что вы идете по правильному пути.Есть много способов сделать это.Какой путь в конечном итоге будет зависеть от ваших целей.

2 голосов
/ 04 января 2011

Я разрабатываю приложение WP7, которое в основном является клиентом существующего REST API.Сервер возвращает данные в формате JSON.С помощью библиотеки JSON.NET (http://json.codeplex.com/) я смог десериализовать ее непосредственно в мои классы .NET C #.

Я храню локально данные для обработки сценария автономной работы моего приложения, а также для предотвращениякаждый раз, когда пользователь запускает приложение, вызывать его на сервере. Я предоставляю два способа обновления данных: вручную и / или через определенный промежуток времени. Для хранения данных я использую Sertling (http://sterling.codeplex.com/), это простой, но простой в использовании локальныйбаза данных для Silverlight / WP7.

Самая большая проблема заключается в обработке асинхронной связи с сервером. Я предоставляю четкие отклики пользовательского интерфейса (индикатор выполнения и / или колесо загрузки), чтобы сообщить пользователю, что происходит.

В дополнение к этому я использую инструментарий MVVM Light и модульное тестирование SL для проведения интеграционного теста View Model => мой локальный код клиента => Server. (http://code.google.com/p/nunit-silverlight/wiki/NunitTestsWp7)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...