Konwersja WebForms do WinForms

2

Szczerze... to bym chyba wolał zrobić konwersję do Blazora z całkowitym oddzieleniem logiki od widoku - bardziej przyszłościowe i chyba szybsze!

2
Neosphoros napisał(a):

Czy więc oznacza to, że strona.aspx.cs może zawierać odnośnik do innego pliku z zdefiniowanymi akcjami? W jaki sposób? Jak to wygląda?

Programowanie to nie jest pisanie plików lecz funkcji, struktur danych i klas. Kod odpowiedzialny za logikę biznesową (czyli to, co Twoja aplikacja ma robić dla jej użytkowników) powinien znajdować się w klasach, które nie są związane z konkretną technologią GUI. Po pierwsze dlatego, że tak jest łatwiej go przetestować automatycznie, po drugie dlatego, że łatwiej go użyć ponownie - np. tworząc inne GUI, jak Ty chcesz to zrobić teraz.

Kristof napisał(a):

Szczerze... to bym chyba wolał zrobić konwersję do Blazora z całkowitym oddzieleniem logiki od widoku - bardziej przyszłościowe i chyba szybsze!

Być może. Ale w ogólności to, co autor chce osiągnąć nie jest problemem. Wystarczyłoby od początku zastosować wzorzec MVP, aby nawet logika prezentacji została taka sama, jedyne co trzeba by było zaimplementować to nowe formularze implementujące interfejsy widoków.

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

Czy więc oznacza to, że strona.aspx.cs może zawierać odnośnik do innego pliku z zdefiniowanymi akcjami? W jaki sposób? Jak to wygląda?

Programowanie to nie jest pisanie plików lecz funkcji, struktur danych i klas. Kod odpowiedzialny za logikę biznesową (czyli to, co Twoja aplikacja ma robić dla jej użytkowników) powinien znajdować się w klasach, które nie są związane z konkretną technologią GUI. Po pierwsze dlatego, że tak jest łatwiej go przetestować automatycznie, po drugie dlatego, że łatwiej go użyć ponownie - np. tworząc inne GUI, jak Ty chcesz to zrobić teraz.

Kristof napisał(a):

Szczerze... to bym chyba wolał zrobić konwersję do Blazora z całkowitym oddzieleniem logiki od widoku - bardziej przyszłościowe i chyba szybsze!

Być może. Ale w ogólności to, co autor chce osiągnąć nie jest problemem. Wystarczyłoby od początku zastosować wzorzec MVP, aby nawet logika prezentacji została taka sama, jedyne co trzeba by było zaimplementować to nowe formularze implementujące interfejsy widoków.

To czy oznacza to, że jest możliwość wskazania z ścieżki zewnętrznej - plik (lub pliki) w których zawierała by się logika funkcjonowania zbudowana już wcześniej podczas np tworzenia wcześniejszych projektów?

0

Nie ze ścieżki (bo programy w C# to nie są połączone ze sobą pliki) lecz z projektu bądź skompilowanego assembly (np. dll).
Ale tak, jest to możliwe. Co więcej, cały świat programistyczny tak działa.

0
somekind napisał(a):

Nie ze ścieżki (bo programy w C# to nie są połączone ze sobą pliki) lecz z projektu bądź skompilowanego assembly (np. dll).

Ale tak, jest to możliwe. Co więcej, cały świat programistyczny tak działa.

No to już nie wiem czy się da czy nie :D
Można wskazać w WebApp/WebForms (lub WinApp/WinForms) ścieżkę z której ma pobierać plik (lub pliki) z logiką programu czy każdorazowo to logikę trzeba kopiować do folderu z nowym projektem i zmieniać mu nazwę na taki by był zbieżny z plikiem .aspx (lub odpowiednikiem dla WinApp/WinForms)?

Czy pliki z logiką można dzielić na części/kilka plików?

1

To ja powtórzę i uściślę.

Przede wszystkim programowanie w C# nie polega na pisaniu plików tylko na pisaniu klas, które zawierają metody (funkcje). Fizycznie te klasy i metody umieszcza się w plikach, ale do elementów kodu nie odwołuje się po nazwach plików lecz po nazwach klas i metod. Po prostu przestań myśleć plikami, zacznij kodem, to znacznie ułatwi zrozumienie interakcji między elementami kodu.

I teraz - w ramach jednej solucji w Visual Studio możesz mieć wiele projektów. Nic nie stoi na przeszkodzie, aby klasy związane z logiką domenową umieścić w jednym projekcie, GUI WebForms w drugim, GUI WinForms w trzecim. Jeśli do projektów GUI doda się referencje do projektu logiki domenowej, to będzie można wykorzystywać dokładnie ten sam kod biznesowy w obu aplikacjach.

0
somekind napisał(a):

To ja powtórzę i uściślę.

Przede wszystkim programowanie w C# nie polega na pisaniu plików tylko na pisaniu klas, które zawierają metody (funkcje). Fizycznie te klasy i metody umieszcza się w plikach, ale do elementów kodu nie odwołuje się po nazwach plików lecz po nazwach klas i metod. Po prostu przestań myśleć plikami, zacznij kodem, to znacznie ułatwi zrozumienie interakcji między elementami kodu.

Ale, żeby wskazać nazwę klasy lub metody to trzeba wskazać nazwę pliku w którym one się znajdują, czyż nie? "Plik" dla mnie ma znaczenie ogólne.

I teraz - w ramach jednej solucji w Visual Studio możesz mieć wiele projektów. Nic nie stoi na przeszkodzie, aby klasy związane z logiką domenową umieścić w jednym projekcie, GUI WebForms w drugim, GUI WinForms w trzecim. Jeśli do projektów GUI doda się referencje do projektu logiki domenowej, to będzie można wykorzystywać dokładnie ten sam kod biznesowy w obu aplikacjach.

Ale załóżmy, że nie ma się jeszcze gotowych projektów z gotową logiką lub interfejsami GUI, ale ma się pojedyncze pliki z gotową (przykładową) logiki programów, to czy konieczne jest utworzenie projektów dla tych plików tylko po to by wskazać referencją - ten "niby projekt"? Nie można wskazać po prostu zewnętrznego folderu z "pomocnymi" plikami logiki (lub klasami jak wolisz)?

0

W normalny sposób nie.

0
somekind napisał(a):

W normalny sposób nie.

To aż dziwne, bo wydawać by się mogło, że byłoby to niesamowicie przydatne. Bo po co niby miałbym wskazywać cały projekt, który zawierać będzie np tylko jeden potrzebny plik/klasę skoro inny i tak korzystałby tylko z pewnych (kilku) plików/klas?

A czy jest przynajmniej możliwość deklaracji większej ilości plików (przepraszam za używanie prawdopodobnie błędnej nomenklatury) logiki w plikach .aspx? Na zasadzie:

CodeBehind="Default01.aspx.cs; kopiowanie_plikow.aspx.cs; obsluga_bd.aspx.cs"
1

Nie można - jeden formularz - jeden "Code Behind". Nie za bardzo w ogóle rozumiem jakby to miało działać w ogóle.

Ogólnie - przestań myśleć o plikach. To nie C. Kompletnie nie ma znaczenia czy klasa jest w takim pliku czy innym, każda klasa w jednym projekcie ma dostęp do każdej innej klasy w tym samym projekcie, nieważne w jakim pliku, nie trzeba podawać nazw tych plików, w zasadzie wszystko mogło by być w jednym i też by działało, a dzielimy na kilka, aby nam było wygodniej.

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