Архитектурное проектирование для приложения Silverlight WP7

Question

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

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

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

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

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

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

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

Мои вопросы:

уже реализовано что-то вроде этого?

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

Вот дизайн я имею в виду:

Есть два компонента, вид и модель.

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

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

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

Answer 1

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

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

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

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

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

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

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

В ваших начальных точках.

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

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

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

Об осуществлении.

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

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

Answer 2

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

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

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

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