Слой сущности данных
Именно на этом слое лежит ответственность за маппинг данных из JSON в десериализированное представление. Данный слой используется для описания классов, осуществляющих объектное или объектно-реляционное преобразование. В сети существует большое количество библиотек, осуществляющих объектно-реляционные преобразования. Например, Newtonsoft.JSON. Однако, не все так радужно. От проблем маппинга они не избавляют.
Поясним что такое маппинг:
Предположим существуют два запроса, которые возвращают одинаковые по структуре данные. Например, пользователей приложения и друзей пользователя, которые обладают таким полями как «идентификатор» и «имя пользователя». Беда в том, что серверные разработчики в одном запросе могут передать поля: «id», «username», а во втором «ident», «user_name». Такое разночтение может иметь целый набор неприятностей:
Сериализированные данные в поле «id» и «ident» могут содержать как строку, так и число. При выводе их на консоль, разницы между двумя числами не будет, но хэш-код у них будет разный, и словарь будет по-разному воспринимать значение этих полей.
Отличия между именами полей являются ответственностью сервера.
Универсального решения этих проблем нет, но они не настолько сложны, чтоб это требовало значительных интеллектуальных усилий.
Слой модели данных
Оперирует моделью данных приложения. Должен содержать классы, представляющие костях модели данных приложения.
Слой локального кэширования
К задачам данного слоя относятся:
Кеширование загружаемых из сети изображений.
Кеширование запросов / ответов сервера
Формирование очереди запросов в случае отсутствия сети и работы пользователя офлайн.
Мониторинг кэшированных данных и очистка данных, срок жизни которых истек.
Уведомление приложения о невозможности получить информацию о заданном объекте из сети.
Существует определенное количество нюансов, которые следует учитывать разработчикам:
– использовать виртуальные методы классов для их кэширования;
– хранение на сервере информации о том, что за кэшировано на клиенте;
– при отсутствии сети запросы на подключение записываются в хранилище, с указанием времени производимого запроса. Когда же подключение возобновляется, производится вычитывание данных из хранилища и передачи из на сервер, с одновременной очисткой очереди запросов. Это дает возможность обеспечить определенную клиент-серверную работу без непосредственного подключения к сети;
Слой рабочих процессов
Все реализованные алгоритмы, которые не относятся к слоям ядра, и не представляют собой GUI должны быть вынесены в классы специфических последовательностей рабочих процессов. Каждый из этих процессов оформляется в своем стиле, и подключается к основной части приложения путем добавления ссылок на экземпляр соответствующего класса в GUI. В подавляющем большинстве случаев, все эти процессы являются не визуальными. Однако имеются некоторые исключения, например, когда необходимо осуществить длинную последовательность предопределенных кадров анимации, с заданными алгоритмами отображения
Вызывающий код должен иметь минимальные знания об этой функциональности.
Один из часто используемых процессов – процесс авторизации пользователя – очевидный претендент на рефакторинг с использованием паттерна «машины состояний».
Каждый вызов слоев ядра сопровождается передачей объекта обратного вызова (callback), и именно через него должно быть возвращено управление в приложение при успешном выполнении команды или возникновения ошибок, либо возможно использование асинхронного программирования.
Локальное хранилище
Существует большое количество способов сохранение временных данных в постоянном хранилище устройства.
Как правило использования постоянных хранилищ призвана обеспечить существенное снижение сетевого трафика, за счёт использования уже полученной из сети информации. Однако, в некоторых случаях это не происходит поскольку источником этой информации является сервер, который и принимают решения относительно актуальности данной информации.
Локальное хранилище на основе файловой системы
Использование словаря в качестве формата полученных данных позволяет автоматически решить еще целый ряд архитектурных проблем:
данные в массивах могут быть представлены точно в той последовательности, в которой они были получены от сервера.
данные однозначно соответствуют используемому запросу к серверу, с точностью до передаваемых параметров в POST запросе (т. е. легко было отличить объекты полученный от определенной команды, от объекта, полученного от той же команды, но с другими данными, переданными в качестве параметров POST пост запроса).
Атомарность записи объекта данных в постоянное хранилище.
Мгновенность и атомарность чтение данных из постоянного хранилища.
Полное соответствие ACID
Отсутствие необходимости в нормализации данных.
Независимость в интерпретации данных.
Все данные всегда актуальны.
Объем кода поддержки минимален (1 строка).
Для чтения сериализированных сохраненных данных нет необходимости в том, чтоб задействовать дополнительную логику. Возврат данных может осуществляться той же командой, которая читает данные из сети.
Отрицательной стороной такого подхода считается, что это плохо влияет на производительность устройства, однако, изучение вопроса показывает, что объем таких данных не превышает 5Кбайт, данные загружаются в память мгновенно, единым блоком, и таким же образом освобождаются из памяти, сразу же после того, как в них отпадает необходимость. В то же время чтение данных блоками (построчно) из базы данных SQL порождает большое количество объектов (на уровне, выходящем за рамки контроля приложения), которые суммарно превышают указанный объем, к тому же, создают дополнительную нагрузку на процессор. Использование центрального хранилище оправдано тогда, когда данные должны сохраняться долгое время, на протяжении многих сессий работы приложения. При этом, данные из сети загружаются частично.
Локальное хранилище на основе средств фреймворка