Часть 2. Архитектура

  • Статья

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

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

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

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

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

  • Уровень данных — сохраняемость ненезависимых данных, скорее всего, база данных SQLite, но может быть реализована с помощью XML-файлов или любого другого подходящего механизма.
  • Уровень доступа к данным — оболочка вокруг уровня данных, предоставляющего доступ к данным для создания, чтения, обновления, удаления (CRUD) без предоставления сведений о реализации вызывающим объекту. Например, DAL может содержать инструкции SQL для запроса или обновления данных, но код ссылки не должен знать об этом.
  • Бизнес-уровень — (иногда называемый уровнем бизнес-логики или BLL) содержит определения бизнес-сущностей (модель) и бизнес-логику. Кандидат на бизнес-фасад.
  • Уровень доступа к службам— используется для доступа к службам в облаке: от сложных веб-служб (REST, JSON, WCF) до простого извлечения данных и изображений с удаленных серверов. Инкапсулирует сетевое поведение и предоставляет простой API для использования слоями приложения и пользовательского интерфейса.
  • Уровень приложений — код, который обычно предназначен для конкретной платформы (обычно не общий доступ на разных платформах) или код, характерный для приложения (обычно не используется повторно). Хороший тест на то, следует ли размещать код на уровне приложения и уровне пользовательского интерфейса (a), чтобы определить, имеет ли класс какие-либо фактические элементы управления отображением или (b) может ли он использоваться между несколькими экранами или устройствами (например, i Телефон и iPad).
  • Уровень пользовательского интерфейса — уровень, доступный для пользователя, содержит экраны, мини-приложения и контроллеры, которыми они управляют.

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

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

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

  • Модель, представление, ViewModel (MVVM) — шаблон Model-View-ViewModel популярен в платформах, поддерживающих привязку данных, таких как Xamarin.Forms. Он был популяризирован пакетами SDK с поддержкой XAML, такими как Windows Presentation Foundation (WPF) и Silverlight; где ViewModel выступает в качестве перехода между данными (модель) и пользовательским интерфейсом (представление) через привязку данных и команды.
  • Модель, представление, контроллер (MVC) — распространенный и часто неправильно понятный шаблон, MVC чаще всего используется при создании пользовательских интерфейсов и обеспечивает разделение между фактическим определением экрана пользовательского интерфейса (представление), подсистемой, которая обрабатывает взаимодействие (контроллер) и данные, заполняющие его (модель). Модель на самом деле является полностью необязательным элементом, поэтому основное понимание этого шаблона лежит в представлении и контроллере. MVC — это популярный подход для приложений iOS.
  • Бизнес-фасад — шаблон AKA Manager предоставляет упрощенную точку входа для сложной работы. Например, в приложении отслеживания задач может быть TaskManager класс с такими методами, как GetAllTasks() , GetTask(taskID) и SaveTask (task) т. д. Класс TaskManager предоставляет фасад внутренней работе фактического сохранения и извлечения объектов задач.
  • Singleton — шаблон Singleton предоставляет способ, в котором может существовать только один экземпляр конкретного объекта. Например, при использовании SQLite в мобильных приложениях требуется только один экземпляр базы данных. Использование шаблона Singleton — это простой способ обеспечить это.
  • Поставщик — шаблон, примечаемый корпорацией Майкрософт (возможно, похож на стратегию или базовую внедрение зависимостей) для поощрения повторного использования кода в приложениях Silverlight, WPF и WinForms. Общий код может быть написан в интерфейсе или абстрактном классе, а конкретные реализации для конкретной платформы записываются и передаются при использовании кода.
  • Async — не следует путать с Асинхронным ключевое слово, шаблон Async используется, если долго выполняющаяся работа должна выполняться, не удерживая пользовательский интерфейс или текущую обработку. В самой простой форме шаблон Async просто описывает, что длительные задачи должны быть запущены в другом потоке (или аналогичной абстракции потока, например задача), пока текущий поток продолжает обрабатывать и прослушивать ответ от фонового процесса, а затем обновляет пользовательский интерфейс при возврате данных и состояний.

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