Руководство по переносу классических приложений

  • Статья

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

  • Код пользовательского интерфейса (например, окна и кнопки)
  • Сторонние элементы управления (например, диаграммы)
  • Бизнес-логика (например, правила проверки)
  • Локальное хранилище данных и доступ
  • Веб-службы и удаленный доступ к данным

Для приложений Windows Forms и WPF, написанных с помощью C# (или Visual Basic.NET), удивительное количество бизнес-логики, локальный доступ к данным и код веб-служб можно использовать на разных платформах.

.NET Portability Analyzer

Visual Studio 2017 и более поздних версий поддерживает анализатор переносимости .NET (скачать для Windows), который может изучить существующие приложения и сообщить, сколько кода можно перенести на другие платформы.

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

"X% моего кода переносим. Что дальше?"

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

Различные фрагменты кода, вероятно, упадут в один из этих сегментов, подробно описано ниже:

  • Повторно используемый переносимый код
  • Код, требующий изменений
  • Код, который не переносим и требует повторной записи

Повторно используемый переносимый код

Код .NET, написанный на основе API, доступных на всех платформах, можно принимать кроссплатформенный без изменений. В идеале вы сможете переместить весь этот код в переносимую библиотеку классов, общую библиотеку или библиотеку .NET Standard, а затем протестировать его в существующем приложении.

После этого общую библиотеку можно добавить в проекты приложений для других платформ (например, Android, iOS, macOS).

Код, требующий изменений

Некоторые API .NET могут быть недоступны на всех платформах. Если эти API существуют в коде, необходимо повторно написать эти разделы для использования кроссплатформенных API.

Примеры этого включают использование API-интерфейсов Рефлексия ion, доступных в .NET 4.6, но недоступны на всех платформах.

После повторного написания кода с помощью переносимых API вы сможете упаковать этот код в общую библиотеку и протестировать его в существующем приложении.

Код, который не переносим и требует повторной записи

Примеры кода, который, скорее всего, не будет кроссплатформенным, включают:

  • Пользовательский интерфейс — экраны Windows Forms или WPF нельзя использовать в проектах в android или iOS, например. Пользовательский интерфейс должен быть перезаписан с помощью этого сравнения элементов управления в качестве ссылки.

  • Хранилище для конкретной платформы — код, основанный на технологии конкретной платформы (например, локальной базе данных SQL Server Express). Вам потребуется повторно написать это с помощью кроссплатформенной альтернативы (например, SQLite для ядра СУБД). Некоторые операции файловой системы также могут быть скорректированы, так как UWP имеет немного разные API для Android и iOS (например, некоторые файловые системы чувствительны к регистру, а другие — нет).

  • Сторонние компоненты. Проверьте, доступны ли сторонние компоненты в приложениях на других платформах. Некоторые, такие как пакеты NuGet, отличные от визуальных элементов, могут быть доступны, но другие (особенно визуальные элементы управления, такие как диаграммы или проигрыватели мультимедиа)

Советы для переноса кода

  • Внедрение зависимостей— предоставление различных реализаций для каждой платформы и

  • Многоуровневый подход — будь то MVVM, MVC, MVP или другой шаблон, который помогает отделять переносимый код от кода для конкретной платформы.

  • Обмен сообщениями— вы можете использовать передачу сообщений в коде для де-пар взаимодействия между различными частями приложения.