2010-08-11 13 views
13

Czy istnieje praktyczny sposób dla nas powoli ewoluować aplikacji WinForms, WPF bez tworzenia koszmar wsparcia dla siebie z dziwnych scenariuszy międzyoperacyjnych?WinForms to WPF - Jak tam dotrzeć?

Informacje ogólne:

Mamy dużą aplikację pancernik szare WinForm, który jest mocno używany przez wewnętrzną grupą około 60-75 użytkowników. Zaczynamy docierać do miejsc, w których moglibyśmy odnieść korzyść z posiadania aplikacji w WPF, ale nie wystarczy uzasadnić duży projekt, aby całkowicie go ponownie napisać. Wszystkie ekrany w aplikacji są samodzielnymi kontrolkami użytkownika WinForms, a aplikacja WinForms to tylko powłoka obsługująca menu, formularze otwierające/zamykające, udostępniające niektóre metody pomocnicze itp.

Do tej pory najlepsze Pomysł, który mieliśmy, to przekonwertować aplikację powłoki do WPF, a następnie hostować kontrolki użytkownika WinForms w środku. Sądziliśmy, że możemy z czasem przekształcić kontrolę użytkowników, wiążąc te zmiany z inicjatywami, które mają wystarczającą wartość biznesową, aby wesprzeć dodatkową pracę. Obawiam się, jak dobrze działa interop i jak wpłynie to na wydajność. Martwię się również, w jaki sposób przechodzimy na nowy wygląd aplikacji. Wydaje się dziwne, aby aplikacja powłoki wyglądała na rozkoszną, a następnie mieć w środku stare, szare kontrolki użytkownika, a także wydaje się dziwne tworzenie aplikacji powłoki w WPF i sprawianie, by wyglądała tak, jak w WinForm.

Jeśli jeden z Caliburn, pryzmat lub innym podobnym ramach ułatwiłoby przejście, chcemy być otwarci na odkrywanie tych opcji, jak również.

Odpowiedz

11

Byliśmy w podobnej sytuacji i wybrał następującą ścieżkę: Na początku zaczęliśmy obsługiwać kilka okien WPF w powłoce aplikacji WinForms (jeszcze). Oczywiście widoczna była pewna różnica, ale celowo zmniejszyliśmy różnicę poprzez tonowanie nowych okien. Doszliśmy do wniosku, że do czasu, kiedy skonwertujemy pozostałe okna/kontrolki, łatwiej będzie "uaktualnić" do bardziej żywych wrażeń, ponieważ interfejs użytkownika będzie całkowicie WPF i możemy zaangażować graficznego projektanta do pracy magicznej w oparciu o XAML.

Osiągnęliśmy teraz punkt, w którym większość okien to WPF. Rozpoczęliśmy proces konwertowania aplikacji powłoki WinForms w opartą na WPF aplikację shellową obsługującą pozostałe WinFormy. Parapety mają nieco nudne kolory, ale użytkownicy zaczęli zauważać różnicę i chociaż jest niewielka, nasi użytkownicy wciąż lubią przyrostową pozytywną zmianę. Nie za długo i wycofamy ostatni WinForm. To będzie moment, w którym wypuścimy graficznych projektantów ze smyczy!

Co do wydajności: Mogę z pewnością nie czyni ogólne oświadczenie, gdyż silnie zależy od poszczególnych kontroli/okien. W naszym produkcie (kilkaset okien) nie znaleźliśmy żadnego istotnego problemu z wydajnością związanego z połączeniem WPF i WinForm.

Nie patrzeć na którymkolwiek z ram, więc obawiam się, że nie mogę ich skomentować.

+1

+1 opisuje ten moje własne doświadczenia bardzo dobrze. Również tutaj jest interesująca sesja PDC o tym, jak Visual Studio 2010 zostało zaimplementowane za pomocą interakcji NET Framework 4: http://microsoftpdc.com/2009/CL09 –

+1

Nie jestem pewien, czy istnieje "odpowiednia" odpowiedź na to pytanie, ale sądzę, że jest to podejście, które najprawdopodobniej w końcu przyjmiemy. –

+0

i przy tych wszystkich wysiłkach, opłaconych przez firmę, czy dostarczyliście użytkownikom końcowym jakiejś użytecznej funkcjonalności, czy po prostu dobrze się bawiliście robiąc oko? – smirkingman

4

Wielkie pytanie, w chwili obecnej większość pracy w WPF dotyczy przekształcania starych aplikacji WinForms, WPF. Z mojego doświadczenia wynika, że ​​najlepszym scenariuszem jest zbudowanie aplikacji od zera w oparciu o starą aplikację/wymagania. Na szczęście byłem częścią projektu, w którym ponownie napisaliśmy aplikację od zera i jestem przekonany, że zajęło to mniej czasu/inwestycji niż połączenie dwóch.

Osobiście uważam, że spowodowałoby to zamieszanie, gdybyśmy spróbowali zmieszać te dwa. Inną kwestią jest to, że trudno będzie wydajnie zaprojektować mieszaną aplikację.

W moim bieżącym projekcie (który jest ogromnym projektem z ostatnich 10 lat), konwertujemy moduł aplikacji według modułów. Na szczęście dla nas nasza aplikacja składa się z różnych mniejszych aplikacji, więc ich konwersja jest łatwiejsza. W twoim przypadku powiedziałbym, że zidentyfikowanie obszarów, które mogą być całkowicie przekształcone w WPF i zacząć budować je w WPF, jak sugeruje tutaj -

Windows Forms - WPF Interoperability FAQ: http://windowsclient.net/learn/integration.aspx

Chciałbym również zasugerować używać niektórych narzędzi do konwersji formularzy Windows na XAML (WPF); to na pewno pomoże ci zaoszczędzić trochę czasu.

Windows Forms konwerter WPF: http://wf2wpf.codeplex.com/

Windows Forms do XAML Converter: http://www.ingeniumsoft.com/Products/WinForm2XAML/tabid/63/language/en-US/Default.aspx

Windows Forms konwerter Prezentacja Foundation Windows: http://www.spiderwan.com/spiderwan/ConvertWinFormToWPF/WinFormToWPF.aspx

+1

Generalnie preferuję metodę stopniowej konwersji opisaną przez Johna, ale zgadzam się, że istnieją momenty, w których uzasadnione jest przepisanie oryginalnych wymagań. Jednak zdecydowanie nie zgadzam się z tym, że Paul G sprawdza narzędzia do konwersji Windows Forms na WPF: Ci, którzy używają takich narzędzi, niezmiennie kończą z aplikacją, która jest jeszcze trudniejsza do utrzymania niż aplikacja WinForm. Poprawnie wykonane, aplikacje WPF są znacznie prostsze i łatwiejsze w utrzymaniu niż odpowiedniki WinForm. Czas poświęcony na tworzenie wysokiej jakości modeli widoków i XAML zostanie zwrócony dziesięciokrotnie, zwłaszcza przy przepisywaniu. –

+0

Punkt wzięty, projektowanie modeli widoków i XAML będzie zawsze lepsze. Chciałem tylko poinformować Paula o dostępnych opcjach (oczywiście w celu zaoszczędzenia czasu). – akjoshi