.NET Standard i .NET Core vs .NET Framework

W życiu każdego developera przychodzi taki moment, że trzeba rozpocząć pracę nad zupełnie nowym projektem. Pojawia się wiele pytań i wątpliwości na temat architektury, języku programowania, frameworków itp. W dużej mierze jest to uwarunkowane specyfiką projektu. Na rynku mamy wiele rozwiązań które pasują lepiej lub gorzej. W tym wpisie nie będę starał się dopasować najlepszych rozwiązań do danej specyfiki projektu, ale skupię się na porównaniu dwóch frameworków od Microsoft’u oraz jak się one mają do trzeciego .Net Standard.

Czym jest .NET Framework a czym .NET Core

.NET Framework to platforma programistyczna opracowana przez Microsoft obejmująca środowisko uruchomieniowe (CLR) oraz biblioteki klas dostarczające standardowej funkcjonalności dla aplikacji. Warto zauważyć, że choć technologia ta nie jest związana z żadnym konkretnym językiem programowania, a programy mogą być pisane w jednym z wielu języków, np. C++, C#, Visual Basic, to dominującym jest C#. Framework dostarcza wbudowanego zarządzania pamięcią (poprzez Garbage Collector) a także wiele predefiniowanych typów danych. Oczywiście za tym hasłem kryje się jeszcze wiele fascynujących feature’ów, ale nie o tym ma być ten wpis.
Więc czym jest .NET Core? To nowa wersja frameworka, która ma być wieloplatformowa oraz open source. Jest to ogromny krok Microsoft’u i ukłon w stronę programistów pracujących na innych platformach niż Windows. A zatem .NET Core będzie działać zarówno na systemach Windows, Linux i macOS. Idea działania .NET Core opiera się na pakietach NuGet. Cały .NET Core to jeden wielki pakiet NuGet. Takie podejście idealnie sprawdzi się w aplikacjach webowych, ponieważ razem z .NET Core dostajemy także ASP.NET Core, co oznacza, że będziemy mogli hostować nasze aplikacje webowe na Linuxie a nawet na macOS’ie. .NET Core ma też swoje wady – nie implementuje pełnego .NET Framework, jest to jedynie podzbiór tej biblioteki. Co możemy więc zrobić przy pomocy .NET Core? – Aplikacje konsolowe, Unit testy, strony ASP.NET MVC, oraz WebAPI. Więc teraz, nasze aplikacje webowe działające pod IIS’em, będziemy w stanie przenieść na Linuxa po dokonaniu delikatnych modyfikacji. Niebawem pojawi się tutaj wpis, jak skonfigurować najtańszy server VPS dostępny na platformach hostingowych tak, aby można było hostować aplikacje .NET Core. Warto dodać, że .NET Core składa się z podstawowej biblioteki klas CoreFX, środowiska uruchomieniowego CoreClr, CoreRT – .NET Native runtimes oraz CLI (command-line interface). Podsumowując, w .NET Core dostajemy wieloplatformowość, modularność i niezależność od .NET Framework (każda aplikacja może korzystać z innej wersji), open source.

Zasadnicze różnice między .NET Framework a .NET Core

Zostało popełnionych wiele ciekawych zmian, które mogą mieć bardzo duży wpływn na programistyczny ekosystem Microsoftu w najbliższych latach. Microsoft pragnie stworzyć programowanie aplikacji cross-platform z każdej platformy tak łatwe i modularne jak Node.js. Mam tylko nadzieję, że stary poczciwy .NET Framework jednak nie pójdzie na razie w zapomnienie. Dla świeżych w temacie, różnice pomiędzy dwoma frameworkami mogą być trochę mylące, ale poniżej przedstawię krótką listę kluczowych atrybutów .NET Core których nie znajdziemy w .NET Framework:

  • Programiści mogą tworzyć jeden wspólny zbiór bibliotek, który może być wspierany przez wiele platform (Linux, macOS, Windows).
  • Programiści mogą tworzyć aplikację na każdej platformie (nie potrzebujemy więcej Windowsa).
  • Można używać tylko bibliotek wymaganych przez aplikację, a reszta bibliotek (CoreFX) została wbudowana dla minimalnych zależności. Te dwie rzeczy oznaczają mniej działań.
  • Mniej działań oznacza mniejszy wpływ na aktualizacje, ponieważ tylko aktualizujemy pakiety, któe używamy. To jest bardzo korzystne dla aplikacji mobilnych, które wymagają niewiele miejsca i aplikacji opartych na chmurze, które wymagają małych aplikacji uruchomionych side-by-side.
  • To wszystko sprawia, że .NET Core jest do 10 razy szybszy od zwykłego .NET Frameworka, ale w zamian za to nie wszystkie funkcjonalności z .NET Frameworka są zawarte w .NET Core.

.NET Framework będzie kontynuował istnienie jako stos używany do tworzenia aplikacji desktopowych od Windows 7 po Windows 10. W rzeczywistości można mieć .NET Framework i .NET Core żyjące razem w jednej solucji, np. w scenariuszu, kiedy GUI napisane w WPF używa API napisanego w .NET Core.

.NET API są zaimplementowane zarówno w .NET Core jak i .NET Framework (choć czasem z róznymi bazowymi implementacjami), .NET Core i .NET Framework posiada także API i możliwości, które są zaimplementowane w jednym, a nie są w drugim i na odwrót. Np. .NET Framework posiada różne frameworki GUI i API specyficzne dla Windows, których nie znajdziemy w .NET Core. Podobnie .NET Core posiada możliwości wieloplatformowe i API, których próżno szukać w .NET Framework. Dodatkowo .NET Framework jest komponentem WIndows, który jest serwisowany i aktualizowany poprzez Windows Updates. .NET Core używa kompletnie inny model egzystencji i aktualizacji.  .NET Core jest stworzony z pakietów NuGet, które są instalowane lokalnie dla aplikacji. To znaczy, że aplikacje, mogą „dostarczać” .NET Core razem z nimi, umożliwiając im istnienie wspólnie z innymi aplikacjami używającymi innych wersji pakietów na tym samym urządzeniu. Serwisowanie wtedy będzie możliwe per aplikacja poprzez manager pakietów, a nie jak dotychczas, poprzez aktualizacje systemu.

O co chodzi z tym .NET Standard

dotnet-today

Na powyższym obrazku widzimy, że każda główna platforma w ekosystemie .NET posiada swoje BCL (Base Class Libraries). BCL, to standardowa biblioteka .NET Framework dla środowiska wykonawczego C# i jedna ze standardowych bibliotek Common Language Infrastructure (CLI). BCL dostarcza reprezentacji typów danych, dostępu do plików, kolekcji, atrybutów, formatowania, bezpieczeństwa, streamów I/O, ciągów znaków i więcej wbudowanych w CLI.  Każda z tych platform, używa BCL’a do komunikacji z API wspólnej infrastruktury (common infrastructure na powyższym obrazku). To znaczy, że każda zmiana w BCL (np. w celu zaimplementowania nowego feature’a dodanego w Common Infrastracture) musiałaby zostać zreplikowana dla reszty BCL czyli .NET Core i Xamarin aby zapewnić synchronizację pomiędzy nimi. W tym momencie, każdy kto musi wspierać wiele platform, z pewnością powiedziałby, że to nie jest łatwe zadanie.

Głównym problemem tutaj jest to, że wspieranie trzech oddzielnych bibliotek (w tym przykładzie, w ekosystemie .NET jest ich dużo więcej) nie jest zadaniem trywialnym, zwłaszcza odkąd Microsoft próbuje zaimplementować .NET na inne platformy (włączając w to różne dystrybucje linuxa a nawet urządzenia IoT).
Nie tylko wspieranie tych trzech bibliotek jest dużym zadaniem. Co jeśli ktoś będzie chciał zrobić porta .NET na nowy system operacyjny? Cóż, będzie musiał zaimplementować własną BCL i zapewnić, że będzie poprawnie komunikowała się z Common Infrastructure, która byłaby kolejną biblioteką, którą społeczność .NET musiałaby synchronizować ze swoimi projektami. Mam nadzieję, że zaczynasz dostrzegać problem. Takie coś doprowadza do sytuacji, że deweloperzy muszą używać warunkowej kompilacji w celu zapewnienia, że biblioteki które używają, dostarczają minimalne API BCL’ów – używając różnych bibliotek dla różnych platform. To znaczy, że Portable Class Libraries nie są już tak przenośne, odkąd deweloperzy którzy je tworzą, nie mogą zagwarantować, że wszystkie wymagane API BCL’ów będą dostępne na platformie docelowej. Więc, jeżeli docelową platformą nie jest Windows, to tak właśnie jest, gdy docelową platformą jest Android lub Linux. I tutaj przychodzi nam z pomocą .NET Standard.

.NET Standard to podejście Microsoft’u do powyższego problemu, które polega na ujednoliceniu API .NET tak, aby działało na wszystkich platformach wspierających .NET, włączając w to IoT i RaspberryPI. Aby móc ujednolicić sposób komunikacji wielu platform wspierających .NET z Common Infrastructure, Microsoft napisał standard, jak powszechne biblioteki BCL powinny działać.
Celem biblioteki .NET Standard jest zamiana sytuacji z poprzedniego obrazku, na tą poniżej:

dotnet-tomorrow

Jak widać, celem jest stworzenie wspólnej biblioteki BCL dla wszystkich platform używających ekosystemu .NET. To powinno zapobiec wszystkim problemom które towarzyszyły istnieniu oddzielnych bibliotek BCL dla każdej platformy.

Bardzo ważną rzeczą w .NET Stadnard dla deweloperów jest to, że mają tylko jedna bazową bibliotekę. Inne biblioteki używające .NET Standard  będą miały możliwość uruchomienia na wszystkich platformach wspierających .NET, w dodatku, dostawcy tych platform, nie muszą zgadywać które API muszą dostarczyć w celu zapewnienia dostępności bibliotek w NuGet.

.NET Standard

Podsumowując, .NET Standard rozwiązuje problem współdzielenia kodu dla programistów .NET na wszystkie platformy, dostarczając wszystkie API których oczekujesz lub lubisz w środowisku które potrzebujesz: aplikacje desktopowe, mobilne, gry i aplikacje działające w chmurze:

  • .NET Standard to zbiór API które wszystkie platformy .NET muszą implementować. To ujednolica platformy .NET i zapobiega przyszłym fragmentacjom.
  • .NET Standard 2.0 będzie zaimplementowany przez .NET Framework, .NET Core i Xamarin. Dla .NET Core doda wiele istniejących API które były pożądane przez programistów.
  • .NET Standard 2.0 zawiera coraz więcej binarek z .NET Frameworka których programiści mogą używać.
  • .NET Standard zastąpi Portable Class Libraries (PCLs) w aplikacjach celowanych na wiele platform.

Poniższy obrazek przedstawia, co zawiera biblioteka .NET Standard:

netstandard-apis

 

Jeśli chciałbyś zobaczyć jak wygląda konkretny zbiór API w .NET Standard 2.0, zajrzyj tutaj: .NET Standard GitHub repository.

W przyszłości napiszę trochę o tym, co daje .NET Standard twórcom własnych bibliotek. Dzięki za dotrwanie do końca, mile widziane uwagi w komentarzach!

1 komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *