Jakie jest właściwe podejście do nowoczesnego interfejsu użytkownika dla aplikacji pulpitu Windows?

Question

Mam istniejącą aplikację z rozbudowanym modelem C++, którą chciałbym podłączyć do ładnego, nowoczesnego interfejsu Windows 7 lub 8. Obecny (antyczny) interfejs użytkownika dla naszej aplikacji został opracowany we wczesnej epoce Windows XP/95/98 przy użyciu czystego API Win32. Nasz kod jest obecnie kompilowanie/linkowanie poprzez Visual Studio 2010.

Wygląda na to, że istnieje wiele różnych "standardów" API programowania: Windows, Win32, MFC, ATL, COM i .NET. W ciągu ostatnich 14 lat moi inżynierowie niemal odholowali linię Microsoftu: w 2001 roku było to "MFC nie żyje - musimy przejść do ATL" (my nie). Wtedy ".NET wymieni MFC" (wydaje się, że nie ma).

Teraz jesteśmy gotowi, aby zrzucić nasz stary kod UI. Byłoby miło pracować z zestawem standardów, które są solidne i wydajne, ale także jednym, który możemy szybko utworzyć interfejs użytkownika. Odkładając na bok QT (na którym czytałem dużo dobrze argumentowanych plusów i minusów tutaj na stackoverflow):

1) Czy nowoczesne podejście do programowania interfejsu użytkownika dla Windows 7 & 8 będzie używać MFC lub .NET?

2) Dla podejścia .NET (zakładając, że istnieją solidne powody wyboru .NET) możemy użyć naszego kodu modelu C++ UNMANAGED z aplikacją .NET?

3) Czy tworzenie oprogramowania Visual Studio 2012 jest niezbędne, nawet jeśli nasza aplikacja początkowo nie byłaby zaprojektowana do prezentacji Metro?

4) Czy są jakieś inne zestawy narzędzi Microsoft, które należy wziąć pod uwagę przy tworzeniu aplikacji?

Stephen

Answer 1

1. Można iść z każdym podejściem. Jednak .NET jest dużo bardziej powszechny w projektowaniu interfejsu użytkownika i ma wiele zalet (jeśli chodzi o szybszy rozwój), jeśli potrzebujesz elastycznego interfejsu użytkownika.

2. Tak. C++/CLI działa dobrze, aby połączyć natywny kod z interfejsem użytkownika .NET.

3. Nie. Możesz to zrobić w VS2010. Mimo to VS 2012 ma wiele zalet, szczególnie podczas pracy z C++. Ulepszenie prawdopodobnie byłoby korzystne.

4. Chciałbym spojrzeć na WPF. Nowy interfejs użytkownika systemu Windows 8 może być interesujący, ale może być trudny w użyciu z poprzednią bazą kodu. Ponadto nie będzie działać na starszych systemach operacyjnych. Z mojego doświadczenia wynika, że ​​WPF jest najlepszą, obecnie poprawiającą się opcją (w programie .NET 4.5 wprowadzono wiele ulepszeń), która obsługuje mieszanie istniejącej bazy kodów z nowymi technologiami interfejsu użytkownika.

Answer 2

Spójrz na this odpowiedź, którą dałem w 2011 roku. Twierdzę, że nadal jest w posiadaniu; może nawet bardziej, biorąc pod uwagę ostatnią zmianę z C++ na Microsoft. Nie wiem, ile dodatkowego wsparcia dla win8 jest w MFC, ale jeśli nie w pełni przełączasz się na Metro (co, jak sobie wyobrażam, nie będzie, jeśli masz "produkt", będziesz musiał obsługiwać starszy Windows przynajmniej przez co, 5 lat?), nie ma to większego znaczenia.

Jeszcze nie widziałem aplikacji .Net/WPF, która wydaje się być "solidna" jak C++ (tak, zdaję sobie sprawę, że są technicznie ortogonalne, ale tak naprawdę, kto buduje .NET UI w C++?). Rozumiem, dlaczego ludzie chcą odejść od MFC; to nie tak, że nie rozumiem jego negatywnych stron. IMO, to, co się sprowadza, to: jak dużą wagę przykładasz do szybkiego rozwoju?W przypadku niektórych zastosowań (linia biznesowa, produkty o krótkim okresie użytkowania) czas wprowadzenia produktu na rynek i szybkość wprowadzania zmian jest ważniejsza niż bycie "solidnie" zaprojektowanym. W przypadku innych (profesjonalne narzędzia, oprogramowanie systemowe) ważniejsze jest tworzenie solidnego oprogramowania o dużym doświadczeniu użytkownika. Mam jeszcze do pokazania oprogramowanie produkcyjne (w przeciwieństwie do "demonstracji tech"), które robią to w bardziej "nowoczesnych" ramach; MFC (a może powinienem powiedzieć "wygraj api używany przez C++", ale MFC pod tym względem wystarcza, aby pozytywy miały negatywny wpływ na negatywy) aplikacje są (nadal) (często) najlepszym narzędziem do tego. IMO.

Jedną ostatnią rzeczą, którą należy rozważyć, są jednak twórcy. Jeśli programowali MFC przez 15 lat, prawdopodobnie programują swoje kariery w jednym miejscu. Jeśli nalegasz na dalsze używanie MFC, możesz je zrazić. Będziesz musiał rozważyć ryzyko biznesowe w tym względzie względy techniczne (biorę z twojego pytania, że ​​jesteś właścicielem firmy). Jeśli wolisz zrobić to prywatnie, możesz skontaktować się ze mną w sprawie dalszej dyskusji.

Answer 3

Naprawdę łatwo powiedziane rozwiązanie byłoby przeniesienie całego kodu C++ do C# lub C++/CLI .NET, a następnie połączenie go z WPF. Może to być skomplikowane, ale lubisz łatwość kodowania w całości w .NET (preferowane są 3.5 SP1 i Visual Studio 2010).

Można również połączyć istniejący kod z .NET, aby korzystać z WPF przez COM Interop. COM Interop zasadniczo rejestruje składnik .NET jako składnik COM w systemie. Gdy zostanie wywołany, CLR wykonuje wykonanie kodu i rozrząd dla twojego programu do wywołania (Więcej informacji - msdn.microsoft.com/en-us/library/zsfww439(v=vs.80).aspx).

Ostatnia metoda polega na zrzuceniu MFC i wywołaniu bezpośrednio w interfejsie API systemu Windows (Win32). Windows API może być łatwiejszy w użyciu z poziomu kodu niż inne metody. W nowoczesnym Windows API, GDI + (Graphics Device Interface) jest zaimplementowany na DirectX (DWM i DXGI) i może być łatwo rozszerzony poprzez COM i jest nieco realną alternatywą dla WPF i Modern UI.

Answer 4

Nikt nie powinien tworzyć nowego projektu opartego na MFC i Win32. Interfejs Windows Mordern i ujednolicone API to przyszłość. Nie sądzę, że .Net jest odpowiedzią na każdą aplikację, szczególnie w przypadku projektów, które mają dużą ilość natywnego kodu C++. Wiemy, że Microsoft pracuje nad ujednoliconym interfejsem API. Mam nadzieję, że jest to odpowiedź na to pytanie.