Jak zaprojektować korporacyjne aplikacje komputerowe dla systemu Windows 8

Wydaje mi się, że rozumiem oczekiwania związane z tworzeniem aplikacji konsumenckich dla systemu Windows 8. Utwórz nowy interfejs użytkownika oparty na metrze na WinRT, wdróż go u klienta za pośrednictwem portalu Marketplace, a wszyscy wygrywają. Wydaje się dość proste. Niestety nie jestem w tym biznesie.

Pracuję na wewnętrznych aplikacjach biznesowych dla dużego przedsiębiorstwa. Obecnie używamy technologii .NET, takich jak WPF i Silverlight, w celu tworzenia bogatych interfejsów użytkownika, które można łatwo wdrożyć dla naszych użytkowników za pośrednictwem Internetu lub ClickOnce. Aplikacje mogą obsługiwać WinXP i Win7 bez nadmiernego bólu głowy, a nasi programiści mogą korzystać z XAML, która jest bardzo solidną technologią interfejsu użytkownika.

Wygląda na to, że WPF i Silverlight mają w tym momencie wątpliwe kontrakty, więc trochę niepokojące jest dalsze inwestowanie w nie. Ale interfejs Metro nie wydaje się odpowiedni dla aplikacji korporacyjnych, a interfejs WinRT API jest dość ograniczony w odniesieniu do „typowych” czynności, które muszą wykonywać aplikacje korporacyjne.

Jak powinienem projektować moje aplikacje oparte na XAML, obecnie wdrażane w WinXP i Win7, aby mogły być obsługiwane i rozwijane na Win8?

Załóżmy na potrzeby tego pytania, że ​​funkcje oferowane przez HTML5 na ASP.NET nie są odpowiednie dla aplikacji, które chcę utworzyć. Rozumiem, że mogę używać HTML5 do niektórych aplikacji, ale staram się dowiedzieć, co powinienem zrobić, gdy to nie wystarczy.

Edycja nr 1: Jest to odpowiedź na komentarz @Emmada Kareema. Zgadzam się, że Silverlight / WPF są rentowne w krótkim okresie (2-5 lat). Jednak aplikacje, które produkujemy, mają potencjalnie bardzo długi okres użytkowania (od 10 do 20 lat). Tak więc przeżywalność w perspektywie długoterminowej dla danej technologii jest dla nas problemem. Obawiamy się również, że coraz trudniej będzie znaleźć programistów zainteresowanych rozwojem Silverlight / WPF, jeśli społeczności te uznają je za „martwe”. Chcę tylko zrozumieć moje opcje i podjąć decyzję z otwartymi oczami.

Jak nauczyłem się przestać się martwić i pokochać stos MS

Nadal możesz uruchamiać aplikacje VB6 w systemie Windows 8 . Zgodność retro na dobre lub złe zawsze była trendem w ekosystemie MS. Nie powinieneś martwić się o przetrwanie technologii takich jak WPF / Silveright, a nawet WinForm pod tym względem.

Z drugiej strony musisz zaakceptować fakt, że w przypadku długoterminowego projektu nigdy nie będziesz mieć najnowszej, najsłodszej technologii.

W rzeczywistości pytania, które powinieneś sobie zadać na temat wyboru technologii, to:

• Czy mój zespół jest wystarczająco wygodny w stosowaniu tej technologii, aby być produktywnym?
• Czy mój zespół chętnie korzysta z tej technologii?
• Czy mogę rekrutować ludzi do tej technologii?

To jest kombinacja odpowiedzi na te pytania, które powinny prowadzić do twojego wyboru, a nie trendy wykute głównie z powodów marketingowych.

Aby uzyskać więcej informacji na temat tej ciągle zmieniającej się technologii, przeczytaj artykuł „Ogień i ruch” Joela Spolsky'ego :

Firmy, które się potykają, to te, które spędzają zbyt dużo czasu na czytaniu liści herbaty, aby ustalić przyszły kierunek Microsoft. Ludzie martwią się o .NET i decydują się przepisać całą architekturę dla .NET, ponieważ uważają, że muszą. Microsoft strzela do ciebie, a to po prostu osłania ogień, aby mogli iść naprzód, a ty nie możesz, bo w taki sposób gra się, Bubby. Czy zamierzasz wesprzeć gradobicie? MYDŁO? RDF? Czy wspierasz to, ponieważ Twoi klienci tego potrzebują, czy też dlatego, że ktoś do ciebie strzela i czujesz, że musisz odpowiedzieć? Zespoły sprzedażowe dużych firm rozumieją ogień osłonowy.

I to zostało napisane prawie dziesięć lat temu.

Architektura i technologie

Architektura i technologie to dwie osobne rzeczy i opcje do zrobienia:

• Możesz zrobić MVC za pomocą WinForm .
• Możesz zrobić MVVM z WPF / Silverlight .
• Możesz zrobić MVC za pomocą ASP.NET .
• O ile nam wiadomo, możesz robić, co chcesz, w tym MVC i MVVM, z WINRT .
• Możesz przejść funkcjonalnie z F # . Dlaczego nie ? Są dziedziny, w których miałoby to sens.
• Możesz wymieszać je wszystkie, aby mieć różne punkty wejścia do wspólnego systemu, a następnie zostać wyśmiewanym, ponieważ staje się zbyt skomplikowany itp.

Możesz korzystać z usług, zasobów, kontroli stron trzecich, ORM itp. Z tymi wszystkimi technologiami, a może, a może nie, z następnymi.

Za pomocą tych wszystkich technologii możesz skręcać i giąć MVC na wiele sposobów: wiązanie czy nie? kod za widokiem czy nie? Kontroler czy nie? ViewModel za każdym razem czy tylko w razie potrzeby? Istnieje wiele sposobów implementacji wzorca projektowego, nawet w ramach jednej konkretnej technologii.

Byłoby nierealistyczne zmuszanie cię do jednego z nich bez zaawansowanej wiedzy o swoim projekcie i zespole. Byłoby to oparte wyłącznie na osobistych preferencjach i skończyłoby się showdownem „moja technologia jest lepsza od twojej”.

Jedyną rzeczą, którą można rzetelnie i obiektywnie zasugerować, jest zastosowanie najlepszych praktyk, które możesz zastosować, aby stworzyć architekturę, która przetrwa próbę czasu, a być może naprawdę będzie przenośna lub ponownie wykorzystana przynajmniej w części z nieznaną technologią w przyszłości . A ta możliwość aktualizacji / przenośności nie powinna nawet być głównym celem Twojej architektury.

Głównym celem Twojej architektury i wybranej technologii jest dostarczenie produktu szefowi / klientowi, który spełnia jego realistyczne wymagania.

MVC (i jego młodszy brat MVVM) okazało się coraz bardziej podstawą solidnej architektury od 1979 roku na arenie języków OOP i nie tylko. Ale wybór konkretnej technologii w 10-letnim projekcie powinien pozostać twoją decyzją.

W mojej książce o MVVM poruszę jedną kwestię, w jaki sposób wykorzystać wzorzec do stworzenia podstawowej aplikacji wielokrotnego użytku. Powinieneś tworzyć natywny interfejs dla różnych platform, na które celujesz (internet, silverlight, telefon, WPF lub WinRT). Ale w przeważającej części można zawrzeć logikę napędzającą interfejs użytkownika za ViewModel.

Wszelkie usługi, do których masz dostęp, powinny być umieszczone za interfejsem (wzór fasady), który jest mniej więcej przenośny między platformami. Interfejs powinien zostać odwzorowany na interfejs API klienta z przodu i przetłumaczony na interfejs API opakowanej usługi z tyłu.

Ta strategia pomaga stworzyć solidną podstawową strukturę, która wymaga tylko nowego interfejsu użytkownika, aby nałożyć na nią warstwę. Pomyśl o tym jako o swoim Modelu Widoku będącym mięśniami, a twoje usługi tworzą szkielet (i narządy). WPF / Silverlight / WinRT tworzą skórkę.

W rzeczywistości jedną rzeczą, na którą zwracam uwagę bardzo wcześnie w mojej książce, jest to, że MVVM nie jest tak nowa, jak się wydaje. Dolphin Smalltalk miał podobny wzorzec, który nazwali MMVC (dwa M to Model aplikacji i Model domeny). ViewModel, którego używamy dzisiaj, jest tylko połączeniem Modelu aplikacji i Kontrolera od MMVC. W rzeczywistości wielu programistów odkrywa, że ​​czasami rozdzielenie ViewModel na dwa komponenty ma sens (kontroler służy do nawigacji i koordynowania wielu maszyn wirtualnych, dzięki czemu maszyna wirtualna może pozostać błogo nieświadoma innych komponentów).

Mówisz, że XAML jest solidny, ale potem WPF ma wątpliwą przyszłość. Chyba, że ​​czegoś mi brakuje, WPF używa XAML i nie widzę, aby te dwie były kiedykolwiek rozdzielone. Czy brakuje mi niektórych wiadomości na temat WPF, które prawdopodobnie wykorzystują inną technologię bazową, lub że Microsoft rozważa zbudowanie jeszcze jednego nowego sposobu tworzenia interfejsów użytkownika? Poza tym wątpię, by WPF nigdzie jechał, ale nie byłby to pierwszy raz, kiedy MS przestało działać z ładunkami naszego kodu ...

Jeśli potrzebujesz bogatej aplikacji interfejsu użytkownika, a HTML5 nie chce jej wyciąć, a Twoja organizacja jest zaangażowana w system operacyjny Windows, myślę, że WPF jest najlepszym wyborem, ponieważ jest to ostatni / największy w tej chwili, z pewnością w porównaniu z WinForm ...

Uważam, że nie powinieneś zbytnio koncentrować się na szczegółach implementacji swoich aplikacji. Jeśli spojrzysz na większy obraz, możesz odizolować swoje zależności technologiczne. Dzięki isolatin zależności np. Xaml / wpf / silverlight masz pewność, że możesz zastąpić komponent / technologię interfejsu użytkownika technologią nowej generacji, a tym samym zagwarantować ciągłość nawet za 20 lat. Pomoże to również odsprzęgnąć komponenty systemu i zmniejszyć wpływ konieczności wykonania takiej wymiany. (W tym zakładam, że dla zapewnienia ciągłości jest w porządku majstrować przy rozwiązaniu umożliwiającym uruchomienie go na platformie nowej generacji)

Innym sposobem zapewnienia izolacji od tych zależności technologicznych jest włączenie wirtualizacji. Jeśli stworzysz swoje aplikacje w taki sposób, że będziesz w stanie uruchomić je w vm, będziesz mógł to zrobić za 20 lat!