Wskazówki dotyczące przenoszenia aplikacji klasycznych

Większość kodu aplikacji można podzielić na jeden z następujących obszarów:

• Kod interfejsu użytkownika (np. okna i przyciski)
• Kontrolki innych firm (np. wykresy)
• Logika biznesowa (np. reguły walidacji)
• Lokalny magazyn danych i dostęp
• Usługi internetowe i zdalny dostęp do danych

W przypadku aplikacji Windows Forms i WPF napisanych za pomocą języka C# (lub Visual Basic.NET) zaskakującą ilość logiki biznesowej, dostępu do danych lokalnych i kodu usług internetowych można udostępniać na różnych platformach.

Analizator przenośności platformy .NET

Program Visual Studio 2017 lub nowszy obsługuje program .NET Portability Analyzer (pobierz dla systemu Windows), który może zbadać istniejące aplikacje i poinformować, ile kodu można przenosić na inne platformy.

Istnieje również narzędzie wiersza polecenia, które można pobrać z narzędzia Portability Analyzer w usłudze GitHub i używane do udostępniania tych samych raportów.

"x% mojego kodu jest przenośne. Co dalej?"

Mam nadzieję, że analizator pokazuje, że duża część kodu jest przenośna, ale z pewnością będzie kilka części każdej aplikacji, której nie można przenieść na inne platformy.

Różne fragmenty kodu prawdopodobnie znajdą się w jednym z tych zasobników, co wyjaśniono bardziej szczegółowo poniżej:

• Możliwy do ponownego użycia kod przenośny
• Kod, który wymaga zmian
• Kod, który nie jest przenośny i wymaga ponownego zapisu

Możliwy do ponownego użycia kod przenośny

Kod platformy .NET napisany względem interfejsów API dostępnych na wszystkich platformach może zostać zmieniony na wielu platformach. W idealnym przypadku będzie można przenieść cały ten kod do przenośnej biblioteki klas, biblioteki udostępnionej lub biblioteki .NET Standard Library, a następnie przetestować go w istniejącej aplikacji.

Biblioteka udostępniona może następnie zostać dodana do projektów aplikacji dla innych platform (takich jak Android, iOS, macOS).

Kod, który wymaga zmian

Niektóre interfejsy API platformy .NET mogą nie być dostępne na wszystkich platformach. Jeśli te interfejsy API istnieją w kodzie, musisz ponownie napisać te sekcje, aby używać interfejsów API międzyplatformowych.

Przykłady obejmują użycie interfejsów API Emocje ion, które są dostępne na platformie .NET 4.6, ale nie są dostępne na wszystkich platformach.

Po ponownym napisaniu kodu przy użyciu przenośnych interfejsów API powinno być możliwe spakować ten kod w bibliotece udostępnionej i przetestować go w istniejącej aplikacji.

Kod, który nie jest przenośny i wymaga ponownego zapisu

Przykłady kodu, który prawdopodobnie nie będzie międzyplatformowy, obejmują:

• Interfejs użytkownika — nie można na przykład używać ekranów Windows Forms lub WPF w projektach w systemach Android lub iOS. Interfejs użytkownika musi zostać ponownie napisany przy użyciu tego porównania kontrolek jako odwołania.

• Magazyn specyficzny dla platformy — kod oparty na technologii specyficznej dla platformy (takiej jak lokalna baza danych SQL Server Express). Należy to napisać ponownie przy użyciu alternatywy dla wielu platform (takich jak SQLite dla aparatu bazy danych). Niektóre operacje systemu plików mogą być również konieczne dostosowanie, ponieważ platforma UWP ma nieco inne interfejsy API dla systemów Android i iOS (np. niektóre systemy plików są wrażliwe na wielkość liter, a inne nie).

• Składniki innych firm — sprawdź, czy składniki innych firm w aplikacjach są dostępne na innych platformach. Niektóre, takie jak pakiety NuGet inne niż wizualizacje, mogą być dostępne, ale inne (zwłaszcza kontrolki wizualne, takie jak wykresy lub odtwarzacze multimedialne)

Wskazówki do tworzenia przenośnego kodu

• Wstrzykiwanie zależności — udostępnia różne implementacje dla każdej platformy i

• Podejście warstwowe — niezależnie od tego, czy MVVM, MVC, MVP, czy inny wzorzec, który pomaga oddzielić przenośny kod od kodu specyficznego dla platformy.

• Obsługa komunikatów — możesz użyć przekazywania komunikatów w kodzie do interakcji między różnymi częściami aplikacji.