Zmiana web app na aplikację okienkową

0

Cześć wszystkim!
Chciałbym zmienić swoją aplikację c#.net web app (forms) na aplikację windows. Która z technologii związanych z Windows jest najbliższa tej, która została już użyta? WinForms, WPF, inne?

4

WinForms.

WinForms i Web Forms są dość zbliżone koncepcyjnie - masz kontrolki i zdarzenia do nich. Tylko oczywiście nie ma np. CSS.

1

Jeśli chodzi o kod C# to najbliżej ma WinForms, tak jak pisał @Ktos, jeśli chodzi o front (html) to WPF, ponieważ XAML jest podobne do HTMLa z WebForms.

0

Wybrałem WinForms z nadzieja, że przeróbka kodu będzie niewielka, ale już na starcie chcąc połączyć się z OleDb wykrywa błąd. Z czego wynika różnica?

Oto kod właściwie działający w webforms:

using System.Data.OleDb;
using System.Data;

namespace Logoowanie
{
    public partial class _Default : Page
    {

        protected void Login_Click(object sender, EventArgs e)
        {
            //string connect = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\Projekty\VisualStudio\2022\Logoowanie\Logoowanie\projekty.accdb";
            //string query = "Select Count(*) From projects Where User_name = ? And User_password = ?";

            OleDbConnection OLEDBConnection = new OleDbConnection();
            OLEDBConnection.ConnectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\Projekty\VisualStudio\2022\Logoowanie\Logoowanie\projekty.accdb; Jet OLEDB:Database Password = 123456Abcd";
            string qry = "Select Account_type from projects Where User_name = ? And User_password = ?";
            OleDbCommand CmdName = OLEDBConnection.CreateCommand();
            CmdName.CommandText = qry;

EDIT:

"Nie można odnaleźć nazwy typu „OleDbConnection” w przestrzeni nazw „System.Data.OleDb”. Ten typ został przesłany dalej do zestawu „System.Data.OleDb, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51”. Rozważ możliwość dodania odwołania do tego zestawu. WinFormsApp1 D:\Projekty\VisualStudio\2022\WinFormsApp1\WinFormsApp1\FormLogowanie.cs 30 Aktywne"

Czy budowa takiej aplikacji jest inna niż webforms? Należy w jakiś inny sposób deklarować połączenia i inne cechy programu?

5

@eninede:

Zależnie od kultury projektu, jeśli miałeś oddzielone dane (modele), kontrolery od robaczków html, to są szanse.

Jeśli miałeś spagetti, szanse lecą na pysk. Nawet trudno sobie wyobrazić stan przejściowy "nie wszystko działa, ale już się kompiluje"

Niestety ten fragment kodu sugeruje negatywny scenariusz. *)
Dokładniej, to skrajnie negatywny - nie widzę żadnych przesłanek, żeby marzyć o choć minimalnie "obiektowym" jest, np odkładanie informacji autoryzacyjnej /autentykacyjnej do struktur obiektów.
Nie, surowe kwerendy w OnClick login. Tragedia.

Nawet znalezienie referencji do jakiejś klasy (co od czasów rozdziału Framerowk / Core oczywiste nie jest) praktycznie niczego istotnego nie rozwiązuje

*) do rabina przyszedł Żyd po poradę w/s inwestycji finansowych. Dał hojne "co łaska", poprosił o analizę, a rabin mu odpowiedział "jest dobrze".
Te mocno zawiedziony, tyle kasy przecież ... "No to Rabe, może coś dłużej"
A rabin: "nie jest dobrze".

1

Brakuje ci referencji w projekcie do System.Data.

Czy budowa takiej aplikacji jest inna niż webforms? Należy w jakiś inny sposób deklarować połączenia i inne cechy programu?

Na pewno. To nie jest www.

PS.
Ogólnie, nie wchodząc w szczegóły, to przepisywanie 1:1 z webforms (moim zdaniem) nie ma sensu i obojętnie w jakiej technologii to zrobisz. Jest MVVM, są ORMy, Access to już prehistoria, czasem jeszcze dochodzi NoSQL, przenosisz ten sam "bałagan" do okien. Większość oprogramowania jest przepisywana na Web ze względu na dostęp, nie zamyka się produktu na jedną platformę, a system operacyjny wtedy nie ma znaczenia jeśli ma dostęp do internetu i przeglądarkę.

1

Nie jestem pewien, czy to będzie dobra porada, ale IMO powinieneś zbudować aplikację dla .NET Framework 4.8 (szablon nazywa się wtedy "Windows Forms App (.NET Framework)" o ile dobrze pamiętam), i wtedy będziesz mógł przenosić swój stary kod "bardziej" 1:1. Ale oczywiście utracisz wszystko, co .NET zyskał od tego czasu.

Ogólnie problem jest taki, że od czasów WebForms wiele się zmieniło, przede wszystkim "nowy" .NET (Core, 5, 6) nie ma pewnych rzeczy wbudowanych i trzeba je dodawać – np. taki OleDbConnection jest teraz w oddzielnym pakiecie, a nie jest częścią biblioteki standardowej.

0

Zakręciliście, że aż się na chwile zamknąłem się w sobie...

Sprawdziłem w WPF i jest podobnie.

Na czym więc polega różnica na przykładzie połączenia z bazą.

W webforms zadeklarować muszę użycie bibliotek poprzez:

using System.Data.OleDb;
using System.Data;

Czy w winforms lub WPF (wygenerowana budowa wygląda identycznie) odbywa się to w inny sposób?

Później w akcji przycisku tworzę mechanikę:

OleDbConnection OLEDBConnection = new OleDbConnection();
            OLEDBConnection.ConnectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\Projekty\VisualStudio\2022\Logoowanie\Logoowanie\projekty.accdb; Jet OLEDB:Database Password = 123456Abcd";
            string qry = "Select Account_type from projects Where User_name = ? And User_password = ?";
            OleDbCommand CmdName = OLEDBConnection.CreateCommand();
            CmdName.CommandText = qry;

            CmdName.Parameters.AddWithValue("", UserName.Text);
            CmdName.Parameters.AddWithValue("", Password.Text);

            OLEDBConnection.Open();

Jak wygląda prawidłowa forma deklaracji bibliotek lub ustanowienie połączenia?

0
eninede napisał(a):

Później w akcji przycisku tworzę mechanikę:

nie

1

Doinstaluj pakiet https://www.nuget.org/packages/Microsoft.Windows.Compatibility, standardowo ODBC nie jest dostępne począwszy od .NET Core 1.0 – bo jest tylko dla Windows, więc jest tylko jako dodatkowa biblioteka.

0
Ktos napisał(a):

Nie jestem pewien, czy to będzie dobra porada, ale IMO powinieneś zbudować aplikację dla .NET Framework 4.8 (szablon nazywa się wtedy "Windows Forms App (.NET Framework)" o ile dobrze pamiętam), i wtedy będziesz mógł przenosić swój stary kod "bardziej" 1:1. Ale oczywiście utracisz wszystko, co .NET zyskał od tego czasu.

Ogólnie problem jest taki, że od czasów WebForms wiele się zmieniło, przede wszystkim "nowy" .NET (Core, 5, 6) nie ma pewnych rzeczy wbudowanych i trzeba je dodawać – np. taki OleDbConnection jest teraz w oddzielnym pakiecie, a nie jest częścią biblioteki standardowej.

Prawdopodobnie masz rację, tyle, że po ostatniej aktualizacji właśnie zauważyłem, że straciłem możliwość tworzenia projektów w wersjach net starszych od 5... i niby dlaczego? Komu to przeszkadzało? Ach ten nasz kochany monopilista-manipulant - Microsoft

1

Sprawdź, bo prawdopodobnie są, tylko w oddzielnych szablonach.

screenshot-20220624115805.png

Windows Forms App -> tylko .NET Core (i wyżej),
Windows Forms App (.NET Frameowork) -> .NET Framework do 4.8.1

Wciaż się da, tylko naokoło.

VS2022 17.3 Preview 2, nowszego nie znajdziesz ;)

0
Ktos napisał(a):

Sprawdź, bo prawdopodobnie są, tylko w oddzielnych szablonach.

No i znowu masz rację. Ale ty jestes mądry :)

Miałeś rację w wszystkim. Połączenie też działa.

Z czego wynikają tak ogromne różnice w tworzeniu kodu między poszczególnymi wersjami? Czy nowe wersje nie powinny sukcesorem starszej?

3

Z tego co widzę na podstawie kodu który udostępniłeś, to będziesz miał niezłe spaghetti w kodzie - pomieszana logika aplikacyjna i biznesowa z warstwą prezentacji i dostępu do danych. Jak już bierzesz się za przepisywanie na WinForms to jeżeli masz na to czas to polecałbym zainwestować w architekturę MVP (Model-View-Presenter) i napisać to "po bożemu".

3

Miałeś rację w wszystkim. Połączenie też działa.

Wspaniale :)

To teraz posłuchaj kolegów @AdamWox i @ZrobieDobrze – skoro trzeba przepisywać aplikację "od nowa" to może warto zastanowić się nad zmianą całej architektury aplikacji, aby była łatwiejsza w rozwijaniu i utrzymaniu – bo za jakiś czas zapytasz jak tego WinForms uruchomić na Linuksie i znów trzeba będzie przepisywać na Avalonię od zera, a przy dobrej architekturze da się zmieniać "frontend" bez gruntownej zmiany całości.

Z czego wynikają tak ogromne różnice w tworzeniu kodu między poszczególnymi wersjami? Czy nowe wersje nie powinny sukcesorem starszej?

Tworząc "nowy" .NET, Microsoft musiał zrezygnować z części kompatybilności wstecz, aby móc to zrobić lepiej i wieloplatformowo. Wspominałem wyżej – w .NET 6 można zainstalować Microsoft.Windows.Compatibility i wtedy też masz nadal ODBC.

2
eninede napisał(a):

Z czego wynikają tak ogromne różnice w tworzeniu kodu między poszczególnymi wersjami?

To nie jest ogromna różnica. To jest doinstalowanie biblioteki, której teraz nie ma domyślnie.
Instalowanie bibliotek to normalna, codzienna praca programisty.

Ogólnie migracja z WebForms -> WinForms nawet takiego spaghetti powinna być relatywnie prosta, bo np. znikną magiczne problemy z Session i innymi webformsowymi patologiami. Problemem może być to, że niektóre kontroli GUI nie mapują się 1:1.

Czy nowe wersje nie powinny sukcesorem starszej?

Bycie sukcesorem polega m.in. na ulepszaniu, a to wymaga pozbywania się złych pomysłów.

Jak Ci nie pasuje, to się przerzuć na Javę - tam cały dług technologiczny jest należycie pielęgnowany i nawarstwiany od 25 lat, i nie ma takich problemów jak w dotnecie.

0
somekind napisał(a):
eninede napisał(a):

Jak Ci nie pasuje, to się przerzuć na Javę - tam cały dług technologiczny jest należycie pielęgnowany i nawarstwiany od 25 lat, i nie ma takich problemów jak w dotnecie.

JSP ?

Lub na pehapa, bo pachnie jakby tam kolega zaczynał.

0

ok. postaram się dostosować. proszę podpowiedz mi jeszcze jedną rzecz.

Czy definicje w elementach webforms lub WPF nie istnieją lub wyraża się je w inny sposób niż webforms?

Zapis taki jak:

Label1.Text = CustomerName;

Przejawia się błędem:

Ważność Kod Opis Projekt Plik Wiersz Stan pominięcia
Błąd CS1061 Element „Label” nie zawiera definicji „Text” i nie odnaleziono dostępnej metody rozszerzenia „Text”, która przyjmuje pierwszy argument typu „Label” (czy nie brakuje dyrektywy using lub odwołania do zestawu?). WpfApp2 D:\Projekty\VisualStudio\2022\WpfApp2\WpfApp2\MainWindow.xaml.cs 49 Aktywne

0

Czy jest więc jakaś technologia MS, która umożliwia na chwilę obecną tworzenie 2 aplikacji (web app i desktop app) bez zmieniania zbyt wielu w kodzie?

1
eninede napisał(a):

Czy jest więc jakaś technologia MS, która umożliwia na chwilę obecną tworzenie 2 aplikacji (web app i desktop app) bez zmieniania zbyt wielu w kodzie?

Technologia nie, separacja logiki od UI tak.

1

Tak naprawdę, to każda.
Głównie chodzi o to, żeby oddzielić warstwę prezentacji od logiki (żeby lepiej zrozumieć koncept, możesz sobie poczytac o takich wzorcach jak np. MVVM, MVC, czy MVP).
Z grubsza chodzi o to, żeby wszelkie eventy z warstwy prezentacyjnej (kliknięcia itp.) przekazywały (tylko) niezbędne informacje do warstwy "niższej" - która "robi robotę", a to co się pokazuje na ekranie pochodziło z informacji przekazywanych z dołu.
Dzięki takiemu podejściu, trzon aplikacji masz zawsze ten sam, a zmieniasz jedynie warstwę prezentacji.

0

Gdyby nie to, że już prawie mi obrzydziliście web forms i WPF to właśnie te 2 technologie można chyba by do siebie przyrównać. Niewiele póki co zmieniłem aby WPF działało tak jak działało web forms.

Jeśli więc mielibyście mnie (jeszcze bardziej) zniechęcić do web forms lub WPF to dlaczego są one takie "BE" ? Dlaczego nowe technologie są takie super, że warto zapomnieć o tych, które używam na tę chwilę?

0
eninede napisał(a):

Jeśli więc mielibyście mnie (jeszcze bardziej) zniechęcić do web forms lub WPF to dlaczego są one takie "BE" ? Dlaczego nowe technologie są takie super, że warto zapomnieć o tych, które używam na tę chwilę?

Działają na linuksie, zabierają mniej zasobów, łatwiej w nich oddzielić GUI od reszty kodu (niejako to wymuszają), nie trzeba się uczyć na pamięć dziwnych konceptów typu cykl życia strony.

3

Jeśli więc mielibyście mnie (jeszcze bardziej) zniechęcić do web forms lub WPF to dlaczego są one takie "BE" ? Dlaczego nowe technologie są takie super, że warto zapomnieć o tych, które używam na tę chwilę?

Kilka miesięcy temu przyszedł ktoś na forum i właśnie pytał o WebForms – i wtedy też był przekonywany, aby to zostawić w spokoju :) A wcześniejsze posty z tej tematyki to rok 2019.

Technologia ta jest już nierozwijana, archaiczna i spotykana praktycznie tylko w projektach legacy. Nowy ASP.NET (Core) jest szybszy, wieloplatformowy, zawiera sporo nowych funkcji, ma lepsze podejście do architektury, co ułatwia testy i wdrażanie. Problemem jest to, że WebForms próbowało ukryć przed programistą działanie jako aplikacja internetowa – dlatego są kontrolki, zdarzenia i cały ten cykl życia strony, a tymczasem protokoły i przeglądarki internetowe jednak tak nie działają. Potem okazywało się, że HTML/CSS/JavaScript idzie do przodu, a WebForms musi kombinować, aby osiągnąć ten sam efekt (np. kontrolki Ajax). A w ogóle wiele dzisiejszych aplikacji internetowych to jest wielka aplikacja kliencka w JavaScript, która tylko pobiera dane z serwera i generowanie HTML nie ma już kompletnie racji bytu.

WPF czy WinForms nie uznaję za specjalnie martwe, ale nie są też specjalnie żywe. Problemem jest to, że w ogóle aplikacje dla komputerów stają się coraz mniej popularne. O ile są to porządne, stabilne platformy, to też nie dostają już raczej nowych funkcji (czasami jakieś poprawki błędów, kompilację dla ARM64 czy inne usprawnienia dla HiDPI) i są – i będą – przywiązane do Windows. Co może być dla ciebie pewnym problemem w przyszłości. Aczkolwiek żadna z nich jeszcze nie ma statusu oficjalnie porzuconej (aczkolwiek Microsoft rzadko oficjalnie porzuca produkty, raczej o nich zapomina...).

0
eninede napisał(a):

Gdyby nie to, że już prawie mi obrzydziliście web forms i WPF to właśnie te 2 technologie można chyba by do siebie przyrównać. Niewiele póki co zmieniłem aby WPF działało tak jak działało web forms.

Jeśli więc mielibyście mnie (jeszcze bardziej) zniechęcić do web forms lub WPF to dlaczego są one takie "BE" ? Dlaczego nowe technologie są takie super, że warto zapomnieć o tych, które używam na tę chwilę?

Co to za aplikacja (dziedzina) ?
Jaka jest jej wielkość (ilość ekranów / tabel / plików źródłowych) ?
jaka jest jej wartość ekonomiczna dla użytkownika ? (bo edukacyjna zerowa albo ujemna)

Wyrokując po fragmencie kodu, ale ważnym, w loginie się skupia to czy ktoś zrobił / chciał po bożemu, czy na pałę (albo w ogóle nie ma orientacji o co chodzi w profesjonalnym programowaniu, czyli "jeszcze nie wie, czego nie wie"). Byłem w różnych projektach, róznie było z jakością, projektem itd. Ale temat autentykacyjno-autoryzacyjny zawsze był robiony z minimum obiektowego designu (chyba że hasło hardkodowane "dupa") . Obok mogło być gorzej, ale a&a zawsze miało jakiś poziom.

Spisać założenia, źródła zaorać, przysypać wapnem, wyrównać walcem.

Zrobić od zera, na green fieldzie, LEPIEJ, z jakaś architekturą, wzorcami itd, w DOWOLNEJ WSPÓLCZENSEJ perspektycznej technologii.
<disclaimer>Być może że ekonomicznie to nie wyjdzie, (bardzo) całkiem możliwe, ze to nie Ty masz zrobić.</disclaimer>

1 użytkowników online, w tym zalogowanych: 0, gości: 1