Jak zaprojektować korporacyjne aplikacje komputerowe dla systemu Windows 8

15

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.

RationalGeek
źródło
Muszę biec na spotkanie, ale mam dla ciebie odpowiedź :)
Michael Brown
2
Dlaczego miałbyś zmienić WPF / Silverlight, który już znasz? Twoje stwierdzenie „WPF i Silverlight mają wątpliwą przyszłość”, cóż, Microsoft nie porzuci tej technologii w ciągu nocy. To, czy będzie nadal rosło, nie jest prawdziwym problemem, jeśli masz dzisiaj wystarczającą funkcjonalność. Krótko mówiąc, musisz mieć solidne podstawy techniczne do rozważenia zupełnie nowej architektury. Niektóre z nich są przerażone, ponieważ ludzie tracą swoje doświadczenie na rzecz innej technologii. Nie mogę ich winić.
NoChance,
3
Chcesz mieć jeden stos technologii na ponad 10 lat? Dlaczego nie skupić się na dobrej architekturze i zasadach projektowania, aby system mógł ewoluować w czasie, aby korzystać z odpowiednich technologii? Spójrz na Visual Studio - istnieje od 1995 roku i ewoluował z czasem. Na przykład program Visual Studio 2010 dodał główne odświeżenie interfejsu użytkownika, które obejmowało użycie WPF i inne zmiany architektoniczne w celu dodania punktów rozszerzalności. Nie możesz kontrolować, jakie technologie lub paradygmaty będą duże w przyszłym roku, a tym bardziej w ramach czasowych, na które patrzysz.
Thomas Owens
5
Co sprawia, że ​​myślisz, że będziesz używać systemu Windows za 20 lat?
JonnyBoats,
1
@JonnyBoats: Ponieważ prowadziliśmy go 20 lat temu ? A może ich główny konkurent opiera się na systemie nawet starszym ? Nie ma sposobu, aby przewidzieć upadek lub przetrwanie określonej technologii.
Matthieu,

Odpowiedzi:

15

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 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ą.

Matthieu
źródło
Całkowicie zgadzam się z tą odpowiedzią. Nigdy nie możesz być tego pewien. Ale istnieje wiele technologii, które mogą zaspokoić postawione pytania, a ja wciąż muszę wybierać spośród nich.
RationalGeek,
@jkohlhepp: dodano akapit dotyczący architektury i technologii. Uważam, że nie można obiektywnie polecić jednej technologii nad drugą lub jednej architektury nad drugą.
Matthieu,
Twoje stanowisko jest takie, że nie ma obiektywnych podstaw do porównywania architektur / technologii? Czy to nie jest celem dyscypliny architektury? Zgadzam się, że chodzi przede wszystkim o wymagania moich szefów. Jednym z tych wymagań jest maksymalna żywotność przy najniższych kosztach, stąd pytanie.
RationalGeek,
@jkohlhepp: Dyscyplina architektury oprogramowania IMHO jest jak medycyna. Zdobywacie doświadczenie w znalezieniu odpowiedniego leczenia konkretnej choroby. Czasami można to zrobić na różne sposoby i próba wyleczenia wszystkich w ten sam sposób przy użyciu tego samego leczenia może być niebezpieczna. Jeśli masz skuteczny zespół doświadczonych programistów w WPF i Silverlight, trzymaj się go i zachowaj swoją istniejącą architekturę. Jeśli musisz to zmienić, nie zmieniaj go tylko dlatego, że istnieją nowe sposoby robienia rzeczy, które już robisz wydajnie, sprzedawane przez Microsoft.
Matthieu,
Mogę wejść na pokład z tym Matthieu. Dzięki za przemyślane odpowiedzi.
RationalGeek,
1

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).

Michael Brown
źródło
Całkowicie zgadzam się co do nakładania różnych części aplikacji. Zgadzam się też całkowicie, że powinieneś uczynić swój interfejs tak głupim, jak to możliwe, ponieważ technologie interfejsu często się psują. Ale nawet po utworzeniu tych warstw nadal można zgadywać, które technologie będą lepsze / tańsze na dłuższą metę.
RationalGeek,
Gdybym musiał zgadywać ... podczas gdy HTML5 jest teraz nową modą, Microsoft będzie nadal wspierał XAML, ponieważ to kontroluje. Nauczyli się tej lekcji od Javy (pierwotnie planowali używać Javy jako najważniejszego języka .NET, kiedy Sun zaczął się z nimi spierać), obsługa HTML jest dostępna. Budowanie aplikacji na solidnych zasadach (deklaratywny interfejs użytkownika wspierany przez bogaty przenośny model obiektowy) powinno pomóc ci przetrwać burzę. Mam nawet przykłady wykonywania MVVM w JavaScript (sprawdź knockout js).
Michael Brown,
0

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 ...

minnow
źródło
Kierunek, który usłyszałem od stwardnienia rozsianego, sugerował, że WPF nie ma długofalowej przyszłości. Ale niczego nie ogłosili. Oczekuję, że wprowadzą go w „tryb konserwacji”, tak jak w LINQ To SQL.
RationalGeek,
WPF jest zdepracowany w systemie Windows 8 (ponieważ nagle zostajesz zrzucony z powrotem do „trybu pulpitu” i zanurzasz się w wciągające wrażenia Metro). Możesz jednak tworzyć aplikacje Metro za pomocą XAML. Są to całkowicie odrębne technologie.
Domenic,
Eee, nie, nie jest przestarzałe, ponieważ pulpit jest nadal kluczową częścią tego doświadczenia. Co do „całkowicie oddzielnych technologii” - naprawdę? Z pewnością znacznie bliżej wariacji na temat, jak ma to już miejsce w przypadku WPF vs. Silverlight (w przeciwieństwie do, powiedzmy, użycia XAML do przepływu pracy ...)
Murph
0

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!

Carlo Kuip
źródło
Z pewnego punktu widzenia rozumiem tę perspektywę. Ja jednak nie trzeba wybrać technologię UI w pewnym momencie, w zależności od tego wyboru będzie wymagać wymiany / aktualizowanie prędzej czy później. Chciałbym dokonać wyboru, który zapewni maksymalną trwałość.
RationalGeek,
Według witryny cyklu życia Silverlight5 będzie obsługiwany do października 2021 r. Support.microsoft.com/lifecycle/?p1=16278 Tak więc niezależnie od tego, co stanie się z mapą drogową, nadal jest to dobry wybór.
Carlo Kuip,