Jak Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) porównuje się do Silverlight i WPF? [zamknięte]

Na najniższym poziomie, WinRT jest modelem obiektowym zdefiniowanym na poziomie ABI. Używa COM jako bazy (więc każdy obiekt WinRT implementuje IUnknown i dokonuje refcountingu), a następnie buduje stamtąd. Dodaje sporo nowych koncepcji w porównaniu ze starymi COM, z których większość pochodzi bezpośrednio z. NET - na przykład model obiektowy WinRT ma delegatów, a zdarzenia są wykonywane w stylu. NET (z delegatami i metodami dodawania/usuwania subskrybentów, po jednej na zdarzenie) zamiast starego modelu COM źródeł zdarzeń i zlewów. Z inne godne uwagi rzeczy, WinRT ma również parametryzowane ("ogólne") interfejsy.

Kolejną dużą zmianą jest to, że wszystkie komponenty WinRT mają dostępne dla nich metadane, podobnie jak. Net assemblies. W COM masz tak jakby z typelibami, ale nie każdy komponent COM je miał. W przypadku WinRT metadane są zawarte w .pliki winmd-zajrzyj do środka "C:\Program Files (x86) \ Windows Kits\8.0 \ Windows metadane\" w Developer Preview. Jeśli grzebać wokół, zobaczysz, że są one rzeczywiście CLI zespoły bez kodu, tylko tabele metadanych. Możesz je otworzyć za pomocą ILDASM. Uwaga, nie oznacza to, że sam WinRT jest zarządzany - po prostu ponownie wykorzystuje format pliku.

Następnie istnieje wiele bibliotek zaimplementowanych w odniesieniu do tego modelu obiektowego-definiujących interfejsy i klasy WinRT. Ponownie, spójrz na folder "metadane Windows" wymieniony powyżej, aby zobaczyć, co tam jest; lub po prostu odpal Object Browser W VS i wybierz "Windows 8.0" w selektorze framework, aby zobaczyć, co jest objęte. Jest tam dużo i nie dotyczy to tylko interfejsu użytkownika - otrzymujesz również przestrzenie nazw, takie jak Windows.Data.Json, Windows.Graphics.Printing lub Windows.Networking.Sockets.

Następnie otrzymujesz kilka bibliotek, które zajmują się konkretnie interfejsem użytkownika - głównie są to różne przestrzenie nazw pod Windows.UI lub Windows.UI.Xaml. Wiele z nich jest bardzo podobnych do przestrzeni nazw WPF / Silverlight - np. Windows.UI.Xaml.Controls jest ściśle dopasowane System.Windows.Controls; ditto dla Windows.UI.Xaml.Documents itd.

Teraz. NET ma możliwość bezpośredniego odwoływania się do komponentów WinRT tak, jakby były złożeniami. NET. To działa inaczej niż COM Interop - nie potrzebujesz żadnych pośrednich artefaktów, takich jak Interop, po prostu /r a .plik winmd, a wszystkie typy i ich członkowie w metadanych stają się widoczne dla ciebie tak, jakby były obiektami. NET. Zauważ, że biblioteki WinRT same w sobie są w pełni natywne ( a więc natywne programy C++, które używają WinRT, w ogóle nie wymagają CLR) - Magia ujawniania tego wszystkiego jako zarządzanego znajduje się wewnątrz samego CLR i jest dość niski poziom. Jeśli używasz programu. NET, który Bibliografiawinmd, zobaczysz, że to faktycznie wygląda jak extern assembly reference - nie ma tam żadnych sztuczek ręcznych, takich jak osadzanie typu.

To również nie jest tępe mapowanie - CLR próbuje dostosować typy WinRT do ich odpowiedników, o ile to możliwe. Więc np. Guidy, daty i Uri stają się System.Guid, System.DateTime i System.Uri, odpowiednio; interfejsy kolekcji WinRT, takie jak IIterable<T> i IVector<T> stają się IEnumerable<T> i IList<T>; i tak dalej. To działa w obie strony-jeśli masz obiekt. NET, który implementuje IEnumerable<T> i przekazuje go z powrotem do WinRT, zobaczy go jako IIterable<T>.

Ostatecznie oznacza to, że Twoje aplikacje. Net Metro uzyskują dostęp do podzbioru istniejących standardowych bibliotek.NET, a także do (natywnych) bibliotek WinRT, z których niektóre - szczególnie Windows.UI - wyglądają bardzo podobnie do Silverlight pod względem API. Nadal masz XAML do definiowania interfejsu użytkownika i nadal masz do czynienia z tymi samymi podstawowymi pojęciami, co w Silverlight - powiązaniami danych, zasobami, stylami, szablonami itp. W wielu przypadkach jest możliwe portowanie aplikacji Silverlight po prostu przez using nowe przestrzenie nazw i dostosowanie kilku miejsc w kodzie, gdzie API zostało dostosowane.

Sam WinRT nie ma nic wspólnego z HTML i CSS, i ma związek z JavaScript tylko w tym sensie, że jest tam również narażony, podobnie jak w przypadku .NET. nie musisz zajmować się HTML / CSS / JS, gdy używasz bibliotek interfejsu użytkownika WinRT w swojej aplikacji. NET Metro (Cóż, myślę, jeśli naprawdę chcesz, możesz hostować kontrolkę WebView...). Wszystkie twoje umiejętności. NET i Silverlight pozostają bardzo istotne w tym modelu programowania.