Konwersja WebForms do WinForms

0
Ktos napisał(a):

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.

Ale w tym wypadku mi chodzi o wygodę w dostępie do informacji i przejrzystość kodu. Przecież łatwiej byłoby podzielić kod na kilka części by nie musieć przeszukiwać tych kilku tysięcy linijek kodu w jednym pliku.

Bo niby dlaczego (czysto teoretycznie) klasa partial nie mogłaby być podzielona na kilka plików cs jeśli tylko przyjmowała by tę samą nazwę?

1

Bo niby dlaczego (czysto teoretycznie) klasa partial nie mogłaby być podzielona na kilka plików cs jeśli tylko przyjmowała by tę samą nazwę?

Może być w kilku plikach. I chyba nawet da się zrobić takie coś, co jak rozumiem chcesz osiągnąć - aby jednemu plikowi .aspx odpowiadało kilka plików .cs. Nie mam teraz ochoty testować, ale na oko powinno działać. Z tym, że nie musisz w ogóle mówić, że to jest w tym pliku i tym pliku i tym pliku - kompilator sam to ogarnie, bo kompiluje wszystkie pliki od razu w jedno.

Ale!

SRP - Single Responsibility Principle. Jedna jednostka kodu (np. funkcja lub klasa) powinna odpowiadać za jedną rzecz. Nie za obsługę zdarzeń formularza, i jeszcze komunikację z bazą danych, i jeszcze zapisywanie do plików i jeszcze logowanie błędów i jeszcze generowanie PDF-ów i jeszcze robienie herbaty. Klasa formularza powinna obsługiwać zdarzenia formularza, klasa bazy danych komunikuje się z bazą danych, a klasa herbaty robi herbatę. One wzajemnie mogą się uruchamiać i komunikować - ale nie muszą wiedzieć w jakich są plikach, bo C# w zasadzie to nie obchodzi, bo wszystko się kompiluje w jednym projekcie do jednego wielkiego pliku DLL.

Ale w tym wypadku mi chodzi o wygodę w dostępie do informacji i przejrzystość kodu. Przecież łatwiej byłoby podzielić kod na kilka części by nie musieć przeszukiwać tych kilku tysięcy linijek kodu w jednym pliku.

No to właśnie wracamy do poprzedniego punktu - dzielimy na mniejsze klasy, odpowiadające za pojedynczą odpowiedzialność, aby nasze klasy nie były zbyt długie i nie miały tysięcy linii kodu w jednym pliku ;)

1
Neosphoros napisał(a):

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?

To jest niesamowite, że już rozwiązujesz nieistniejące zupełnie w języku problemy, kiedy Twoim podstawowym problemem jest niezrozumienie idei podziału kodu na klasy, tworzeniu obiektów i odwoływaniu się do nich. Może warto na chwile odpuścić Formsy jedne i drugie, a nadrobić braki w podstawach?

Neosphoros napisał(a):

Bo niby dlaczego (czysto teoretycznie) klasa partial nie mogłaby być podzielona na kilka plików cs jeśli tylko przyjmowała by tę samą nazwę?

Albo nie zrozumiałem o co Ci chodzi albo partial tak faktycznie działa.

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

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?

To jest niesamowite, że już rozwiązujesz nieistniejące zupełnie w języku problemy, kiedy Twoim podstawowym problemem jest niezrozumienie idei podziału kodu na klasy, tworzeniu obiektów i odwoływaniu się do nich. Może warto na chwile odpuścić Formsy jedne i drugie, a nadrobić braki w podstawach?

Nie umiem w inny sposób. Nie jestem typem "czytacza" i nie czułbym ognia jeśli musiałbym przedzierać się przez strony książki po to by dopiero na ostatniej stronie znaleźć rozwiązanie problemu. Bardziej wolę analizować kod i na jego podstawie starać się zrozumieć to czego konkretnie szukam. Wielość informacji w Internecie na szczęście mi w tym pomaga.

Neosphoros napisał(a):

Bo niby dlaczego (czysto teoretycznie) klasa partial nie mogłaby być podzielona na kilka plików cs jeśli tylko przyjmowała by tę samą nazwę?

Albo nie zrozumiałem o co Ci chodzi albo partial tak faktycznie działa.

Może działa, ale chyba nie w sposób o jaki mi chodzi... a przynajmniej nie znalazłem rozwiązania:

https://stackoverflow.com/questions/23996069/how-to-create-multiple-code-behind-file-for-aspx-page

Edit:

To https://social.msdn.microsoft.com/Forums/en-US/7fd970d2-05da-4b6d-8dfc-7634ee45566f/splitting-the-code-behind-file-into-multiple-files?forum=aspgettingstarted chyba jednak rozwiązuje problem?

Nie rozumiem jednak w jaki sposób aplikacja wie, że ma czytać plik MyPartialClass.cs . Gdzieś go trzeba zadeklarować?

1

Nie rozumiem jednak w jaki sposób aplikacja wie, że ma czytać plik MyPartialClass.cs . Gdzieś go trzeba zadeklarować?

W momencie kiedy kompilujesz swój projekt wszystkie pliki, które wchodzą w skład projektu są łączone "w jedno". Więc dopóki dodajesz plik do projektu w Visual Studio nic nie musisz deklarować, "samo" się zrobi. Skompilowany projekt nie ma odniesień do plików źródłowych.

(więc tak naprawdę "deklarujesz" dodając plik do projektu VS)

1

nie wiem czy o to ci chodzi ale w WinForms oddzielasz widok od logiki używając wzorca MVP https://www.google.com/search?q=mvp+winforms ; w WPF - MVVM.
Piszesz presenter / viewmodel który skala logikę z widokiem a logikę możesz trzymać całkiem osobno. W ten sposób z widokiem trzymasz tylko minimum niezbędnego kodu powiązanego z samym widokiem (nie ma sensu go oddzielać) a osobno masz dll-kę z logiką którą teoretycznie przy dobrej separacji możesz współdzielić w aplikacji webforms i winforms

0
Ktos napisał(a):

Nie rozumiem jednak w jaki sposób aplikacja wie, że ma czytać plik MyPartialClass.cs . Gdzieś go trzeba zadeklarować?

W momencie kiedy kompilujesz swój projekt wszystkie pliki, które wchodzą w skład projektu są łączone "w jedno". Więc dopóki dodajesz plik do projektu w Visual Studio nic nie musisz deklarować, "samo" się zrobi. Skompilowany projekt nie ma odniesień do plików źródłowych.

(więc tak naprawdę "deklarujesz" dodając plik do projektu VS)

Hmmm. Ok. Mądry ten VS.
Czyli jeśli w default.aspx.cs wypisze warunek powiązujący wybór z DDL, a później dodam do projektu nowy plik klasy .cs o tej samej nazwie klasy, to po dodaniu funkcji button_click bedzie ona mogła wiązać akcję DDL z default.aspx.cs?

To samo będzie się działo z innymi plikami aspx.cs o ile tylko klasa ich będzie mieć taką samą nazwę co nowododany plik cs?

0
Neosphoros napisał(a):

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?

Z tego, co udostępnia .NET też używasz mniejszości, pewnie nawet nie 1% klas. Jaki w tym widzisz problem?

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