Cześć, muszę napisać aplikacje pulpitową przetwarzającą dane z czujników i na ich podstawie będę robił rysował wykresy na żywo, w sumie to będzie jej główna funkcjonalność na chwilę obecną. Jakoś nie przepadam za WPF, w czym teraz pisze się aplikacje pulpitowe? Prosiłbym o jakieś słowa klucz żebym sobie pogooglował. Dzięki :)
0
1
winforms albo wpf co tu więcej pisać. Jest jeszcze UWP ale to działa od Win10
0
Raczej łatwo i przyjemnie się to zrobi w winformsach, o których już wspomniał abrakadaber
1
Jeśli będziesz chciał to do wykresów możesz rozważyć użycie https://lvcharts.net/
1
tylko nie idź w stronę Electrona.
0
Dziś w ogóle nie pisze się aplikacji desktopowych. A jeśli już, to na Windowsa Microsoft proponuje WPF i tyle. WinForms jest prostsze tylko dla początkujących i dla tych, którzy nauczyli sie złych praktyk i próbują je dalej stosować. Dla pozostałych, WPF ułatwia utrzymanie porządku i czystego kodu, WinForms z kolei to utrudnia.
0
Od kiedy to sie nie pisze aplikacji desktopowych? :)
0
@Slepiec: nie mówilem, że nie widziałem dobrze napisanej aplikacji w WinForms. Mówię, że WinForms tego nie ułatwia, a wręcz odwrotnie.
0
@RideorDie: Jeśli potrzebujesz jakiś super_hiper_bajerów_animacji lub innych śmieci w UI to WPF. Jeśli nie, to zarówno WPF jak i WinForms. Dla początkującego WinForms będzie prostsze, ale może to moje złudzenie bo ja od tego zaczynałem desktopowe w .NET (bo WPF wtedy nie było).
@krzywy Programista: masz jakieś realne dane na ten temat? Nie znam żadnego większego systemu biznesowego w WPF. Ty znasz?
MS to sobie może proponować (co zresztą robi od lat) różne rzeczy. Czasem jakoś nie trafiają. Cały poważny przemysł jaki znam jest na WinForms (jeśli coś jest w .NET), a widziałem nawet ciepłownię na linuxowych desktopach.
No i w jaki sposób biblioteka UI może wpływać na utrudnienia w pisaniu porządnych aplikacji? Co jest takiego w WPF co nie utrudnia? Nie znam WPF więc się chętnie dowiem.
0
@jacek.placek: Sam pisałem projekt w WPF, czy była to mała aplikacja - nie powiedziałbym, znajduje się ona we wszystkich sklepach na wszystkich komputerach obsługujących sprzedaż, był to system typu POS (point of sale), dla jednego z największych dystrybutorów elektroniki w Polsce. To, że takie systemy nie są za bardzo widoczne, to nie znaczy że ich nie ma.
Wg mnie w obecnych czasach nie ma sensu siadać do Windows Forms (sam w nim programowałem przez parę lat). Jeśli chcesz w WPF też zrobisz code behind i też będzie "łatwo". Dodatkowo autor postu zaznaczył, że ma to być aplikacja z wykresami i w tym przypadku WPF ma przeogromną przewagę, gdyż GUI jest renderowane przez DirectX i generowanie wykresów będzie działać znacząco szybciej.
0
No to właśnie jest bardzo mała aplikacja.
0
@jacek.placek: a system ERP dla przedsiębiorstwa z 50 tys pracowników?
0
No i to jest przykład. Ja nie traktuje swoich pytań jako konkurs kto ma dłuższego tylko autentycznie chce się dowiedzieć
Bo to, że jakaś aplikacja jest używana na milionie urządzeń nie czyni z niej dużego systemu. Notatnik jest w milionach pecetów.
Pytanie czy wybór WPF-a do tego systemu był podyktowany jakimiś specyficznymi dla WPF-a zaletami?
Bo to, że jest nowszą technologią i pewnie bardziej przyszlosciowa to ja rozumiem i planując nowy duży projekt to się można zastanawiać.
Ja, nie znając WPF-a nie widzę jakiś realnych korzyści na takim przejściu. Dlatego się dopytuję. Multimedia i dx9 to dla mnie popierdulki. Może system bindigu, cos z samej architektury?
0
@jacek.placek: To się tak zawsze wydaje, "co może być w systemie sprzedażowym", a jak zaczynasz go robić to się okazuje, że logika biznesowa jest bardzo skomplikowana. W końcu zrobienie aplikacji trwało 2 lata dla 4 zespołów 6 osobowych (ok 15 programistów). Cormarch XL, Microsoft Dynamic CRM czy jakaś Enova to nie jest, ale na pewno nie była to mała aplikacja.
Jeśli tworzyłbyś kiedyś większą aplikację (ja robiłem dużego CRM) to wiedziałbyś dlaczego unikać Windows Forms. Zacznijmy od tego, że użytkownicy i tym bardziej osoby zlecające stworzenie aplikacji wchodzą na wiele portali www itd i są przyzwyczajeni do nowoczesnego UI, chcą mieć ładną aplikację - i nie ma się co dziwić, każdy patrzy na wygląd. No to teraz... zrób ładne style kontrolek w Windows Forms, już mogę wysyłać zestaw żyletek do cięcia siebie. Kolejne problemy zaczynają się z renderowaniem, które w Windows Forms jest bardzo wolne. Dla przykładu, mając Grida który wyświetla 1000 rekordów z ok 20 kolumnami (nie zawsze miały one tekst, czasami ikonkę, czasami checkbox, czasami przycisk), to odpytanie WCF, przerobienie filtru na zapytanie SQL, wykonanie zapytania SQL, mapowanie danych + serializacja 2x (wejście/wyjście z WCF) zajmowały mniej czasu niż samo renderowanie UI...
Załóżmy teraz, że chcesz na Gridzie wyświetlić 10 000 wierszy i chcesz, aby każdy wiersz miał swój przycisk Edytuj (tak wiem, że lepiej zrobić jeden globalny, ale to jest przykład! :)) No i... nie da się w Windows Forms, tzn da się, ale aplikacja się wywali. Czemu? Każda kontrolka w Windows Forms "zjada" jeden uchwyt, domyślny limit uchwytów per pojedynczy proces w Windowsie to 10 000. Więc w czystej teorii: okno główne (1 uchwyt), Grid (2 uchwyt), i zostaje miejsce dla 9 998 przycisków... - limit można podnieść, ale chyba nie o to chodzi.
Dodatkowo w WPF masz binding i dzięki temu można użyc MVVM, powstały kod może być lepiej napisany (jakościowo) oraz w dużej mierze przetestowany.
0
Nie wiem czego to wynika, ale jakoś często tu w dyskusjach ludzie piszą teksty typu "jakbyś tworzył duży system...". Mało kto tu zna innych. Pisz co uważasz a nie co ktoś robił czy nie robił. Poważnie to nie wygląda.
Z POS miałem ostatnio do czynienia z 12 lat temu. Chyba jeszcze wpf-a nie bylo ale jakoś się dało.
Piszesz o 1000 rekordow i 20 kolumnach. To jakis żart z tym wolnym renderowaniem? Jakoś nie zauważyłem. Jedyne na co ostatnio ktoś narzekał to na chart bo mu się ładuje 5-6 sekund. Ale tam jest 9 serii po min. 40000 punktów na serię i.nikt się mad tym na razie nie skupiał.
Na cholerę komuś 10000 wierszy w gridzie? Kto z białkowych to ogarnie? Sam czas generowania to jakieś dziwne info. Nie chce mi się szukać, ale chyba w devex piszą o 1M rekordów poniżej 100ms no ale pewnie na samych wartościach tekstowych. Dla WPF-a też pewnie da się wymyśleć absurdalne przykłady.
Na cholerę komuś ładne style kontrolek? Te co są np. w Debbexpress nie wystarczają? Imho w biznesowych to popirrdólki. Ja rozumiem jakiś ogólny wygląd ale bez przesady. Z moich doświadczeń wynika, że lepiej poświęcić czas na dopracowanie pod kątem UX a nie wyglądu. Gdzie sa kontrolki, w jakiej kolejnosci, czy maja obsluge klawiatury odpowiednia itd. Osobiście nie spotkałem klienta, który by mi zaplacił za ladny wyglad. Moze taka specyfika.
W winforms też można przetestować kod. Tez możesz uzyc mvvm. Ogolnie zobacz, ze kiedys nie bylo wpf-a a jakies duże systemy powstawaly.
A co do tej waszej sprzedażowe to dobrze rozumiem, że piszesz, że implementowaliscie złożoną logikę sprzedazową w terminalu POS?
Liczyłem na jakieś techniczne konkrety.
1
Hej, sorry - jeśli robimy duży system dla biznesu to wybór silnika GUI jest sprawą drugorzędną.
Tu logika i tak musi być po stronie webserwisów i to logika biznesowa jest najważniejsza.
A wygląd ? Widziałeś kiedyś SAP'a? Piękny jest ? Nie powiedział bym. Mega szybki i responsywny ? Trochę lepiej ale też nie jest mistrzostwo świata.
1
jacek.placek napisał(a):
Pytanie czy wybór WPF-a do tego systemu był podyktowany jakimiś specyficznymi dla WPF-a zaletami?
Bo to, że jest nowszą technologią i pewnie bardziej przyszlosciowa to ja rozumiem i planując nowy duży projekt to się można zastanawiać.
Ja dołączyłem do tego przedsięwzięcia w jego dość zaawansowanej i jedynej słusznej fazie (przenosiny na web), ale zakładam, że twórcom tamtej wersji mogło chodzić o łatwość uzyskania efektownego GUI oraz ładniejszego kodu w warstwie prezentacji.
W WPF gotowe kontrolki są ładniejsze o tych w WinFormsach i znacznie łatwiej je modyfikować oraz stylować. Sama organizacja kodu w WPF ułatwia pisanie ładnego kodu. Oczywiście ułatwia, a nie gwarantuje, tylko różnica jest taka, że WPF trzeba zadziałać wbrew schematom, aby wymieszać prezentację z logiką, a WinForms wymaga zdobycia większej wiedzy o wzorcach i dobrych praktykach, aby ładnie separować.
Szalony Szewc napisał(a):
Załóżmy teraz, że chcesz na Gridzie wyświetlić 10 000 wierszy i chcesz, aby każdy wiersz miał swój przycisk Edytuj (tak wiem, że lepiej zrobić jeden globalny, ale to jest przykład! :)) No i... nie da się w Windows Forms, tzn da się, ale aplikacja się wywali. Czemu? Każda kontrolka w Windows Forms "zjada" jeden uchwyt, domyślny limit uchwytów per pojedynczy proces w Windowsie to 10 000. Więc w czystej teorii: okno główne (1 uchwyt), Grid (2 uchwyt), i zostaje miejsce dla 9 998 przycisków... - limit można podnieść, ale chyba nie o to chodzi.
Tak, tylko jeśli ktoś wpada na tak szalony pomysł jak 10 tys wierszy w gridzie, to równie dobrze może chcieć ich tam wepchnąć 1 miliard, i wtedy nawet WPF padnie. :)
Ale zakładam, że takie niegospodarne zarządzanie uchwytami to faktycznie jest jakiś narzut na wydajność, więc zapewne lepiej go unikać. Rozumiem, że WPF robi to lepiej.
jacek.placek napisał(a):
Na cholerę komuś ładne style kontrolek? Te co są np. w Debbexpress nie wystarczają? Imho w biznesowych to popirrdólki. Ja rozumiem jakiś ogólny wygląd ale bez przesady.
Przecież klienci kupują wzrokiem, zwłaszcza jeśli to jakieś wysoko postawione szyszki w korpo. Nieważne, czy system jest stabilny i wygodny, ważne żeby ładnie wyglądał. I generował kolorowe wykresy. :P
0
W WPF gotowe kontrolki są ładniejsze o tych w WinFormsach i znacznie łatwiej je modyfikować oraz stylować.
Tak, ale w WinForms się nie piszę jakichś realnych interfejsów bez komponentów z DevExpress-a, Telerik-a czy innych. Ja sobie nie wyobrażam. Te gotowe są po prostu żałosne. Śmiem twierdzić, że w WPF też bym pewnie używał DevExpresowych gridów (ze świetnymi edytorami komórek) czy chartów. Mi się nie opłaca tracić x godzin na np. edytor filtrów w gridzie. Jak ktoś trochę używał takich dodatków to wie, ze bez nich się po prostu nie da a cena jest nieistotna :)
Zresztą w webowych jest chyba podobnie. Na typowych kontrolkach html-owych nie da się nic konkretnego zrobić. Z dodatkami z DevEx. czy Telerik można niemal to samo co w WinForms, nie mówiąc już o js-owych frameworkach.
Przecież klienci kupują wzrokiem, zwłaszcza jeśli to jakieś wysoko postawione szyszki w korpo...
No niby tak chociaż ja mam jakieś wyjątkowe szczęście w tej kwestii. Może dlatego, że działam głównie w MSP i tam często ludzie od zarządzania są dość blisko tych od roboty. Na tyle blisko, żeby słyszeć jak bluzgają na jakieś kolorowe bajery :)
0
jacek.placek napisał(a):
Tak, ale w WinForms się nie piszę jakichś realnych interfejsów bez komponentów z DevExpress-a, Telerik-a czy innych. Ja sobie nie wyobrażam. Te gotowe są po prostu żałosne. Śmiem twierdzić, że w WPF też bym pewnie używał DevExpresowych gridów (ze świetnymi edytorami komórek) czy chartów. Mi się nie opłaca tracić x godzin na np. edytor filtrów w gridzie. Jak ktoś trochę używał takich dodatków to wie, ze bez nich się po prostu nie da a cena jest nieistotna :)
Owszem, ale nawet te piękne zestawy kontrolek nie oferują wszystkiego, co jest potrzebne. Czasami trzeba coś napisać samemu. I tu znowu w WPF będzie łatwiej niż w WF.
W WinFormsach jakieś bardziej zaawansowane osadzanie kontrolek w kontrolkach, zmiana ich zachowania albo sposobu wyświetlania może być naprawdę mordęgą, włącznie z sięganiem do WinAPI. Wiem co mówię, bo różne cuda robiłem, także rozszerzając np. telerikowego grida.
0
Tak, nie oferują wszystkiego i mi też się zdarzyło z raz czy dwa. W WPF też pewnie trzeba czasem ostro rzeźbić :)
Uzgadniamy, że w WPF jest łatwiej operować w UI. Miałem nadzieję, ze ktoś WPF-owy binding opisze w kontrze do WF.
0
jacek.placek napisał(a):
Miałem nadzieję, ze ktoś WPF-owy binding opisze w kontrze do WF.
Ale to link do tutoriala chcesz? Bo trochę nie rozumiem...
0
Nie, opis doświadczeń typu w WF 5 godzin a w WPF 15 godzin :)
0
W sensie dowód pod tezę? ;>
0
No ale tego dużo jest po netach:
Miałem nadzieję, ze ktoś WPF-owy binding opisze w kontrze do WF.
Widziałem tam nawet versus zrobiony.
0
@somekind: Dokładnie :) Na razie z argumentów pojawiły się tu lepsze możliwości w UI i naturalniejsza, czy niejako wymuszana, możliwość poprawnego pisania.
Miałem nadzieje na wpis typu, pisaliśmy erpa w WF i nie było tragicznie, ale pisaliśmy też erpa w WPF i było lepiej bo: 1..., 2..., 3...., 4...
@grzesiek51114 Ja mam pewną awersję do tutoriali bo często tam jest tyle błędnych praktyk, że strach zaglądać. Może w tych do WPF jest inaczej, ale wątpię.
0
Myślę, że jeśli chodzi o Windowsowy desktop to w technologię XAML wartość pójść, ponieważ MS zaczyna powoli wyrzekać się Win32. Starczy poczytać artykuły na portalach tematycznych. Na ile się to rozwinie to nie wiem, niemniej nie zmienia to faktu, że nowe, poważne aplikacje desktopowe dla Windowsa to dzisiaj w większości WPF.
PS: faktem jest również to, że desktop przeżywa poważny kryzys ale to już inna para kaloszy.