Часть 2 — Архитектура приложения

Архитектура приложенияКлючевым принципом построения кроссплатформенных приложений является создание архитектуры приложения, которая поддается максимизации совместного использования кода на разных платформах. Придерживаясь следующих принципов объектно-ориентированного программирования можно создать хорошо спроектированные приложения:

  • Инкапсуляция — обеспечение, что бы классы и даже архитектурные слои только предоставляли минимальный API, который выполняет необходимые функции и скрывает детали реализации. На уровне класса это означает, что объекты ведут себя как «черные ящики» и что для использование кода не нужно знать, как классы выполняют свои задачи. Для архитектурного уровня это означает реализацию шаблонов как фасад, которые используют упрощенный API, который управляет более сложным взаимодействием от имени кода в более абстрактных слоях. Это означает, что код пользовательского интерфейса (например) отвечает только за отображение экрана и принимает пользовательский ввод; и никогда не взаимодействует с базой данных напрямую. Аналогичным образом код доступа к данным предназначен только для чтения и записи в базу данных, но никогда не взаимодействует непосредственно с кнопками или надписями.
  • Разделение обязанностей – обеспечение, чтобы каждый компонент (как на уровне архитектуры, так и на уровне класса) имел ясные и четко определенные цели. Каждый компонент должен выполнять только свои определенные задачи и раскрывать этот функционал через доступный для других классов API-интерфейс.
  • Полиморфизм — Программирование для интерфейса (или абстрактного класса), который поддерживает несколько реализаций. Это означает, что основной код может быть написан и общими для всех платформ, и, в то же время, взаимодействуя с особенностями конкретных платформ.

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

Типичные уровни приложений

На протяжении всего этого документа и тематических исследований, мы ссылаемся на следующие шесть слоев архитектуры приложений:

  • Уровень данных — Энергонезависимая хранилище данных, вероятно, это будет база данных SQLite, но может быть реализовано или с файлами XML или с любым другим подходящим механизмом.
  • Уровень доступа к данным – оболочку вокруг слоя данных, который обеспечивает доступ к данным для создания, чтения, обновления, удаления (CRUD), не раскрывая подробности реализации вызывающему.
  • Бизнес-уровень – (иногда называемый уровнем бизнес-логики или BLL) содержит определения бизнес-сущности (модель) и бизнес-логики.
  • Уровень доступа к сервисам — Используется для доступа к службам в облаке: от сложных веб-служб (REST, JSON, WCF) до простого поиска данных и изображений с удаленных серверов. Инкапсулирует сетевое поведение и обеспечивает простой API, для использования уровнями приложения и пользовательского интерфейса .
  • Прикладной уровень – как правило, платформозависимый код (как правило, не общий для всех платформ) или код, который является специфическим для приложения (как правило, не многоразового использования).
  • Уровень пользовательского интерфейса (UI) – Слой, ориентированный на пользователя, содержит экраны, виджеты и элементы управления, которые управляют приложением.

Приложение может не содержать все слои – например уровень доступа к сервисам не будет существовать в приложении, которое не имеет доступа к сетевым ресурсам. Очень простое приложение может объединять уровень данных и уровень доступа к данным.

Основные модели мобильного программного обеспечения

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

  • Модель, представления, контроллер (MVC) – общая и простая модел, наиболее часто используется при создании пользовательских интерфейсов и предусматривает разделение между фактическим определением пользовательского интерфейса — экрана (представления), механизм, стоящий за ним, который обрабатывает взаимодействие (контроллер), и данные (модель). Модель является на самом деле совершенно необязательной частью и поэтому ядро понимания этой модели заключается в представлении и контроллере.
  • Бизнес фасад – как модель управления, обеспечивает упрощенную точку входа для сложных работ. Например, в задаче отслеживания приложений, может потребоваться класс TaskManager с методами, например GetAllTasks(), GetTask(taskID), SaveTask (task) и т.д. Класс TaskManager обеспечивает фасад для внутренней работы фактически сохранения/извлечения объектов задачи.
  • Синглтон – модель предоставляет способ, в котором может существовать только один экземпляр определенного объекта. Например, при использовании SQLite в мобильных приложений, требуется только один экземпляр базы данных.
  • Провайдер – модель придумана Microsoft (возможно Стратегия или Основа внедрения взаимосвязи) для поощрения повторного использования кода между Silverlight, WPF и WinForms приложений. Общий код может быть написан в виде интерфейса или абстрактного класса, пишутся реализации под конкретную платформу, когда код используется.
  • Асинхронная модель – не следует путать с ключевым словом Async, асинхронная модель используется, когда операции должны быть выполнены без задержки пользовательского интерфейса или для текущей обработке длительных операций. В своей простейшей форме, асинхронная модель просто описывает, что длительные задачи должны быть запущены в другом потоке в то время, пока текущий поток продолжает обрабатывать задачи и ожидает ответа от фонового процесса, а затем обновляет пользовательский интерфейс при возврате данных и/или состояния.

Каждая из моделей будет рассмотрен более подробно, поскольку их практическое применение иллюстрируется в тематических исследованиях. В Википедии есть более подробные описания моделей Фасада, Синглтона, Стратегии и ПровайдераМоделей проектирования в целом).

Оригинал статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *