Cześć
Chciałbym stworzyć system za pomocą .NET framework. System ten składałby się z dwóch aplikacji: desktopowa (WinForms App) oraz webowa (ASP.NET core Web App). Powinienem stworzyć Web Api (ASP.NET Core Web API) do komunikacji z bazą danych? W jaki sposób połączę warstwę serwerową (web api) z warstwą kliencką (w szczególności WinForms)? Czy macie jakieś sprawdzone kursy/poradniki/książki, które pomogą mi przy tworzeniu tego systemu?
Z góry dziękuje za każdą pomoc
A warstwę API z klientem łączy się tym co wystawia API - może to być HTTP, może być coś innego. W okienkowym kliencie trzeba by mieć HttpClient i parsować odpowiedzi.
Jeśli już musisz tworzyć aplikacje desktopową to zainteresuj się WPF/UWP/WinUI. Na pewno przyjemniej się w tym pracuje niż WinForms.
Aby komunikować się z aplikacji desktopowej do WEB API wystarczy użyć klasy HttpClient.
Nie musisz tworzyć WEB API, jeśli to ma być aplikacja lokalna, na jednym komputerze. Wtedy bezpośrednio z aplikacji łączysz się do bazy za pomocą ORM, np. EntityFramework.
Jeśli aplikacja ma działać w sieci, nawet lokalnej to poczytaj o architekturze klient-serwer. Tutaj też nie musisz tworzyć API. Wystarczy połączenie np. TCP.
Chciałbym podszkolić się w tworzeniu takich aplikacji. A co jeśli owa aplikacja desktopowa będzie posiadać więcej możliwości niż aplikacja webowa? Wtedy lepiej bezpośrednio łączyć się z bazą? Niech przykładem będzie tworzenie systemu sprzedaży jedzenia w restauracji. Strona webowa służyć będzie jedynie dla klienta do zamawiania posiłków, natomiast aplikacja desktopowa będzie potrzebna pracownikom do obsługi restauracji (sprzedaż posiłków, zapis historii sprzedaży, dodawanie nowych rzeczy do menu, generowanie raportów, rachunków, faktur).
Angular lub React.JS będzie lepszym pomysłem?
@Piotr.Net: Tak jak wspomniałem koledze wyżej. Przykładem będzie tworzenie systemu sprzedaży jedzenia w restauracji. Strona webowa służyć będzie jedynie dla klienta do zamawiania posiłków, natomiast aplikacja desktopowa będzie potrzebna pracownikom do obsługi restauracji (sprzedaż posiłków, zapis historii sprzedaży, dodawanie nowych rzeczy do menu, generowanie raportów, rachunków, faktur itp).
Moim pierwotnym planem było stworzenie API, które spełniać będzie wszystkie potrzebne wymagania, a następnie stworzyć aplikacje desktopową i webową, które komunikowały by się z owym API w celu pozyskania odpowiednich informacji.
jaros555 napisał(a):
A co jeśli owa aplikacja desktopowa będzie posiadać więcej możliwości niż aplikacja webowa? Wtedy lepiej bezpośrednio łączyć się z bazą? Niech przykładem będzie tworzenie systemu sprzedaży jedzenia w restauracji. Strona webowa służyć będzie jedynie dla klienta do zamawiania posiłków, natomiast aplikacja desktopowa będzie potrzebna pracownikom do obsługi restauracji (sprzedaż posiłków, zapis historii sprzedaży, dodawanie nowych rzeczy do menu, generowanie raportów, rachunków, faktur).
Nie wiem skąd przywiązanie do technologii okienkowych. Takie rzeczy (i setki bardziej razy skomplikowane) od dawna robi się w webie. Nawet argument o tym, że "no, ale trzeba mieć Internet!" już pada, bo nawet kasy fiskalne wymagają dostępu do Internetu lub jak już ktoś nie chce tego hostować w chmurze to może sobie odpalić na serwerze na zapleczu i mieć dostęp po LAN. Okienka to zostały już do jakiś ciężkich rzeczy, CAD, grafika itp.
Wiadomo, że dla klienta i dla pracownika będą to inne serwisy, ale oba z powodzeniem mogą być webowe.
@Saalin: Chce po prostu zobaczyć "z czym to się je". Dopiero jestem na początku drogi z .NET i chciałbym znać pełne spektrum możliwości zanim podejmę decyzję w czym chcę się bardziej rozwijać. Moje pytanie dalej brzmi z jakich narzędzi korzystać i jaką architekturę najlepiej zastosować.
To zamiast porywać się z motyką na słońce i projektować jakiś rozległy system to zrób jakiś działający fragment tego, więc wg mnie na początek samo Web Api do takiego systemu z bazą danych, a później jakiś front do tego (obojętnie czy Angular czy React) albo jakiś Blazor, żeby pozostać w obszarze .NET. Albo wszystko razem w jednej aplikacji jako Web App (Razor Pages). Nie wszystko naraz.
Książek ani kursów niestety nie polecę, nie kojarzę w tym momencie nic od podstaw.
@Saalin: Oczywiście, że nie wszystko będę robił w jednym momencie. Projekt ten chcę rozplanować na kilka dobrych miesięcy (długie wakacje, chęć nauki).
Na ten moment widzę to tak:
Jeszcze mam pytanie odnośnie samej architektury. Tak jak wspomniałem wcześniej, aplikacja desktopowa będzie dużo bardziej rozbudowana. Czy w moim API powinienem zawrzeć wszystkie funkcjonalności, czy tylko te, które współdzielone są z aplikacja internetową (zamawianie jedzenia), a reszta będzie obsługiwana przez aplikacje desktopową bezpośrednio na bazie danych. A może powinienem stworzyć dwa osobne API (jedno API dla klienta pod zamawianie na stronie internetowej, drugie API stworzone do obsługi restauracji dla pracowników)?
Z góry dziękuje za wszelką pomoc, już dużo rzeczy mi się rozjaśniło
Jeśli miałaby to być ta sama baza co do API to nie, dostęp do bazy powinien być realizowany jedynie przez API. Chyba, że aplikacja okienkowa trzyma swój stan w swojej bazie danych, ale wtedy dochodzi problem synchronizacji różnych baz danych.
@Saalin: Okej, czyli najsensowniej będzie stworzyć jedno rozbudowane API do obsługi bazy. Obie aplikacje będą komunikować się z bazą za pomocą API.
Bardzo dziękuje za pomoc
Tak jak tu było wspominane: nie ma w obecnych czasach sensu robić aplikacji desktopowej. Desktopowe to mogą być proste narzędzia, a lepiej wszystko robić jako aplikację webową. Masz wtedy tylko jedną technologię do ogarnięcia. Jak koniecznie chcesz by była uruchamiana na desktopie to to też dalej może być aplikacja webowa (np. Blazor).
Też kiedyś brnąłem w win formsy, potem wpf'a i jest to zupełnie zbędny kierunek, a samo asp.net core czy angular na froncie zapewni Ci i tak nadmiar wiedzy do zdobycia i pokryje prawie cały rynek ofert pracy. Nie ma sensu zajmować się niszą, bo skończysz ze zmarnowanym czasem i wiedzą, która nie będzie za bardzo przydatna.
Straszne bzdury piszecie o braku sensu WinForms. Prawie cały przemysł i chyba większość erpow jest na desktopach. A tekst, ze w web od dawna robi sie tak samo skomplikowane UI jak na deskropach to juz kuriozum. 90% apliakcji web w UI maks 20 komponentów.
Trend jest oczywisty i jest to web i mobile ale desktop, bynajmniej, nie umarł. Zalezy czym ta aplikacja ma byc.
Koszt wejścia w WinForms jest znacznie niższy niż web api + front i to jeszzce w js. Chociażby dlatego, że nie trzeba API. Jeśli aplikacja jest lokalna to WinForms to równie bobry wybór co web. Pomijam specyfikę aplikacji bo nie wiemy co to ma być A może się okazać, że lepiej zrobić desktop + mobile.
Po,a tym API nie gada z db tylko z domeną aplikacji po do nie UI na desktopie.
Jeśli to nauka i c# to na web bym poszedł w Blazora.
jacek.placek napisał(a):
Straszne bzdury piszecie o braku sensu WinForms. Prawie cały przemysł i chyba większość erpow jest na desktopach.
Jeśli to nauka i c# to na web bym poszedł w Blazora.
No ta, tylko to nie jest tak, że ktoś sobie siadł roku czy dwa lata temu i stwierdził - A weźmy se pierdzielnijmy system w WinFormsach xD
To istnieje tylko i wyłącznie dlatego, że naklepano pierwszą wersję 15-20 lat temu i teraz trzeba utrzymywać ze smutnymi panami z bankowości i systemów magazynowych.
@jacek.placek: Prawdziwy desktop nie umarł ale stał się specjalistyczny do dużych projektów, a nie drobnych rzeczy. Ja już nie pamiętam kiedy ostatni raz instalator czegokolwiek ściągałem. W żadnej firmie z którą współpracowałem też zawsze stare desktopowe apki się przepisywało na webowe. ERPy na desktopie? :D to te z lat 90tych i wcześniejsze :D Jak ktoś chce mieć zacięcie do bycia archeologiem, to nikt nie broni.
@urke: Nie. To dlatego, że do niedawna webowe UI były strasznie upośledzenie. Ale to naprawdę strasznie.
Teraz są jsowe frameworki, które znacznie to poprawiają ale web wymaga dodatkowej infrastruktury, kompetencji. Dodatkowe zagrożenia itp. Są też oczywiste plusy web apps.
Oczywiście rynek idzie w web ale to nie znaczy, że zjada istotnie desktop. To znaczy troche zjada ale nie zje do końca.
@wasiu: No właśnie. Jest bardziej specjalistyczny. To nie są apki z horoskopami dla psów.
No nie sciagales instalatorów bo cały gowno-kontent jest w web. Ja nie twierdzę, że web jest gorszy czy mniejszy ale do nauki jest ok. Początkujący to w web nawet z komunikacją sobie nie poradzą.
Erpy nie te z lat 90 tylko te co są używane w firmach.
To, że ktoś nie pisze debilnych, animowanych UI nie znaczy, że chce być archeologiem. W normalnych aplikacjach UI to ile? 10-15%?
Ja kończę bo to i tak nie na temat.
@jaros555: Olej UI.
Napisz domenę aplikacji. Jedyny UI to testy.
Potem napisz API do tego. A potem UI w czym chcesz.
Desktop nie wymaga API. Wystarczy domena aplikacji i nie musi to być domeną w sensie DDD.
Jak będziesz chciał się pochwalić to UI w web w jakimś frameworku js, Blazorze, Flutterze na mobile...
Jestem dopiero na początku przygody z .NET i zrobienie tej aplikacji desktopowej na pewno mi nie zaszkodzi (nigdzie mi się nie śpieszy). Zamiast tej dyskusji co jest lepsze, dużo łatwiej byłoby mi zacząć gdybyście wyszczególnili co warto zrobić i za pomocą czego.
Na ten moment widzę to tak:
1. API stworzone w ASP.NET Core Web API
2. Aplikacja internetowa stworzona w Angular / React.js
3. Aplikacja desktopowa stworzona w WPF/UWP/WinUI
4. Baza danych MS SQL Server (Entity framework)
Co do tej aplikacji desktopowej to w końcu podłączać to pod API czy nie? Który sposób implementacji będzie lepszy?
Z góry dziękuje
Jeśli baza będzie w sieci lokalnej to WinForms bez API. APi jest takim samym UI jak web czy WinForms.
Jeśli baza będzie w publicznym Internecie to dostęp do bazy przez API. Chodzi glownie o to, żeby nie wystawiać bazy z publicznym dostepem.
Co ta aplikacja ma robić?
@jacek.placek: Chce stworzyć system sprzedaży jedzenia w restauracji. Strona webowa służyć będzie jedynie dla klienta do zamawiania posiłków, natomiast aplikacja desktopowa będzie potrzebna pracownikom do obsługi restauracji (sprzedaż posiłków, zapis historii sprzedaży, dodawanie nowych rzeczy do menu, generowanie raportów, rachunków, faktur itp).
To strasznie rozległy projekt / grupa projektów.
Coś tam się obiektywnie nauczysz, coś nauczysz się nieco dziwnych rzeczy (apka dekstopowa integrowana z REST'em, zamiast z lepszymi protokołami), bez wsparcia od kompilatora, na stringach.
I ogrom pracy na szerokość, przez dziesiatki endpointów
To nie jest dobry pomysł do nauki.
(a że nie jestem pewien bezinteresownej nauki, podkreślę: TO NIE JEST DOBRY PROJEKT NA PIERWSZĄ FUCHĘ)
@ZrobieDobrze: Temat po prostu wymyśliłem w celu łatwiejszego wyznaczenia celów, równie dobrze może być to system zarządzania sklepem (aplikacja webowa do sprzedaży produktów, aplikacja desktopowa do zarządzania magazynem) czy system rezerwacji biletów w teatrze. Branie takiej fuchy przy mojej wiedzy byłoby nieodpowiedzialne xD
Ok.
Web dla klientów i do zarządzania ( raporty, konfiguracja).
Aplikacja stanowiskowy do restauracji na desktopie. WinForms, MAUI albo zobacz Fluttera. Głównie że względu na komunikację z terminalami płatniczymi, drukarką paragonów itp. Na webie będą z tym problemy.
Ja od niedawna przenoszą takie stanowiskowe aplikację na Fluttera. Tablety z Androidem A ostatnio Flutter na Windows. Nie sprawdzałem jeszcze komunikacji z urządzeniami ale nie spodziewam się dużych problemow.
@jaros555:
Myślę, że temat trochę zboczył, bo ludzie bardziej cenią czas i piszą czego się bardziej opłaca uczyć.
I na Twoim miejscu zadałbym sobie pytanie "w czym chcę robić w przyszłości"?
Oczywiście pisząc aplikacje desktopową lepiej będziesz się obchodził z językiem C#, ale równie dobrze to możesz osiągnąć przy pomocy aplikacji konsolowej - to bez nauki żadnych XAML'ów.
Zdarzają się oferty pracy, gdzie wymagają znajomość WinForms/WPF itp., ale wątpię czy to nowe projekty. Raczej utrzymanie/rozwijanie dawno napisanych aplikacji albo przepisywanie aplikacji desktopowej na web'ową.
A co do tematu.
Aplikacje, które planujesz zrobić powinny być wielostanowiskowe, więc konieczne jest utworzenie serwera z API i po prostu komunikowanie się do tego API z poziomu aplikacji desktopowej/webowej.