Struktura folderów/plików/klas w projekcie

Witam,

moje pytanie dotyczy sposobu projektowania układu folderów/plików/postów w przypadku aplikacji Windows Forms tworzonych w Visual Studio.

Generując nową formatkę (Forms) w Visual Studio, powstają 3 pliki:

• główny plik <nazwaFormatki>z klasą danego Forms,
• plik <nazwaFormatki>.Designer.cs zawierający metody odpowiadające za wygenerowanie wyglądu/układu formatki.
• plik <nazwaFormatki>.resx.

W swoim projekcie, dla każdej formatki (Forms'a) tworzę dodatkowy plik, zawierający klasę danej formatki z przedrostkiem partial, po to aby nie zaśmiecać kodu w głównym pliku formatki.

Główny plik formatki zawiera:

• deklaracje zmiennych,
• konstruktory,
• wywołania funkcji odpowiadających za obsługę zdarzeń. Jednak faktyczna treść tych funkcji jest już w tym dodatkowym pliku.

Oprócz tego, w projekcie mam kilka innych plików, zawierających klasy odpowiadające za różne zadania "ogólno-projektowe", np. klasa dbModel zawierająca wszelkie funkcje odpowiadające za komunikację z bazą danych.

Co sądzicie o moim sposobie na porządkowanie kodu?

Czy znacie może jakieś lepsze, praktycznie stosowane przykłady na porządkowanie kodu? Szczególnie zależy mi na informacji od osób, które zawodowo pracują jako programiści/inżynierowie oprogramowania .NET.

Ferrari napisał(a)

W swoim projekcie, dla każdej formatki (Forms'a) tworzę dodatkowy plik, zawierający klasę danej formatki z przedrostkiem partial, po to aby nie zaśmiecać kodu w głównym pliku formatki.

Ale dlaczego? Pierwszy raz się z tym spotykam.

Czy znacie może jakieś lepsze, praktycznie stosowane przykłady na porządkowanie kodu? Szczególnie zależy mi na informacji od osób, które zawodowo pracują jako programiści/inżynierowie oprogramowania .NET.

W zależności od architektury rozwiązania i typu aplikacji, ale robi się oddzielne projekty na GUI, na obsługę bazy danych, na infrastrukturę projektu, na logikę biznesową, kontrolery, itp.

somekind napisał(a)

Ferrari napisał(a)

W swoim projekcie, dla każdej formatki (Forms'a) tworzę dodatkowy plik, zawierający klasę danej formatki z przedrostkiem partial, po to aby nie zaśmiecać kodu w głównym pliku formatki.

Ale dlaczego? Pierwszy raz się z tym spotykam.

Chciałem oddzielić warstwę interfejsu, od warstwy obliczeniowej aplikacji. Tak jak wspominałem mam też osobny plik/klasę, który stanowi swego rodzaju model bazy danych. Są tam wszystkie funkcje implementujące poszczególne zapytania do bazy danych.

Zatem mój projekt posiada 3 warstwy:

• interfejsu (domyślnie generowane przez Visual pliki formatek),
• obliczeń (dodatkowe pliki dla każdej formatki, tworzone przeze mnie, z wykorzystaniem słowa partial),
• danych (klasa zawierająca implementację zapytań do bazy danych).

Może powinienem myśleć o czymś takim jak MVC dla Windows Forms? Tylko czy to nie będzie wyważanie już otwartych drzwi? Bo jednak większą część interfejsu mojej aplikacji "wyklikuję" za pomocą Visual Studio. Mniejszą część interfejsu generuję w kodzie, ale to tylko kiedy mam do czynienia z dynamicznie zmieniającym się wyglądem formatki. Może właśnie trzymanie kodu interfejsu w plikach *.Designer.cs, realizuje model MVC? A cała moja zabawa z osobnym plikiem dla warstwy obliczeniowej jest niepotrzebna, i powinienem wszystkie obliczenia trzymać w głównym pliku formatki?

somekind napisał(a)

Ferrari napisał(a)

Czy znacie może jakieś lepsze, praktycznie stosowane przykłady na porządkowanie kodu? Szczególnie zależy mi na informacji od osób, które zawodowo pracują jako programiści/inżynierowie oprogramowania .NET.

W zależności od architektury rozwiązania i typu aplikacji, ale robi się oddzielne projekty na GUI, na obsługę bazy danych, na infrastrukturę projektu, na logikę biznesową, kontrolery, itp.

</quote> A czy mógłbyś mi podać jakieś źródła gdzie mogę więcej poczytać na ten temat? Ewentualnie słowa/frazy kluczowe. Czy "Projektowanie systemu informatycznego", "Implementacja systemu informatycznego" to dobry kierunek poszukiwań?

Będę wdzięczny za wszelkie info.

Struktura folderów:

/src - wszelkie Twoje źródła
/test - testy jednostkowe
/docs - dokumentacja
/lib - biblioteki, które wykorzystujesz w aplikacji
/bin - skompilowane .dll i exe

A w src tworzysz strukturę projektów. Tutaj powinny się znaleźć projekty w architekturze wielowarstwowej, czyli np. rozdział na UI - Logikę biznesową - Bazę danych.

Czyli w Twoim przypadku formy powinieneś mieć w projekcie UI. Formatki, będą reagować na akcje użytkownika i dalsze obliczenia będą wykonywane przez klasy z projektu np. LogikaBiznesowa. A z kolei odwołania do bazy danych będą tylko z projektu logiki biznesowej.

Są to przykładowe konfiguracje, ale przypuszczam, że w większości projektów informatycznych coś w ten deseń jest używane. Aczkolwiek jest to struktura, która może być dużo bardziej rozbudowana w zależności od rozmiarów projektu.

Pozdrawiam
Łukasz Gawron

Ferrari napisał(a)

• interfejsu (domyślnie generowane przez Visual pliki formatek),
• obliczeń (dodatkowe pliki dla każdej formatki, tworzone przeze mnie, z wykorzystaniem słowa partial),

Zamiatasz śmieci pod dywan. ;)

Może właśnie trzymanie kodu interfejsu w plikach *.Designer.cs, realizuje model MVC?

Nie. To tylko oddziela automatycznie wygenerowany kod od napisanego ręcznie.

A cała moja zabawa z osobnym plikiem dla warstwy obliczeniowej jest niepotrzebna, i powinienem wszystkie obliczenia trzymać w głównym pliku formatki?

To tworzy bałagan i ogromne pliki, utrudnia testowanie i nie jest obiektowe.

A czy mógłbyś mi podać jakieś źródła gdzie mogę więcej poczytać na ten temat? Ewentualnie słowa/frazy kluczowe. Czy "Projektowanie systemu informatycznego", "Implementacja systemu informatycznego" to dobry kierunek poszukiwań?

Po części dobry, do tego dochodzą "architektura wielowarstwowa" i "wzorce projektowe".

Obliczenia powinny być w zupełnie innych klasach, całkowicie niezależne od kodu formatek. W plikach Form.cs powinien być tylko kod obsługujący żądania użytkownika i wywołujący metody z klas "obliczeniowych". Z MVC nawet dobrze trafiłeś, chociaż moim zdaniem w przypadku aplikacji WinForms miło pracuje się z MVP.

Jakiś czas temu wrzuciłem przykład aplikacji bazującej na MVP, od tamtej pory parę osób podziękowało mi za niego i uznało za dobry... Chociaż ja średnio w to wierzę.
W każdym razie: http://4programmers.net/Forum/C_i_.NET/171908-winforms_wzorzec_mvp_-_moje_boje?p=701088#id701088

Czas przebudować moją solucję, ale zanim to zrobię, jeszcze mocniej rozczytam się w temacie. Dzięki Wam za szczegółowe wyjaśnienia!

somekind - dzięki za odnośnik do tematu o MVP. Jest on zbieżny z moim, ściągnąłem sobie Twoją aplikację i będę bazował na jej przykładzie.

W swoim projekcie korzystam z dwóch źródeł danych:

• baza SQL Lite (poczytam o NHibernate),
• zewnętrzne SDK (Ebay SDK for .NET).
  Generalnie większość danych w aplikacji ma pochodzić z SDK, baza SQL Lite jest właściwie tylko do celów pomocniczych.

Planuję zrobić tak, że w projekcie Model, będę miał dwa foldery:

• DataBase - zawierający Model bazy danych,
• SDK - zawierający klasy Ebay SDK.

Wydaje mi się, że Model to najlepsze miejsce dla SDK. Jak sądzicie?

Model to klasy, na których operujesz w aplikacji, np. Klient, Produkt, Zamówienie... Źródła danych typu baza danych czy pliki to warstwa Data Access. Wydaje mi się, że Ebay jest dla Ciebie również źródłem danych, więc komunikacja z nim powinna się odbywać w tej warstwie. Za mało podałeś szczegółów odnośnie projektu, żeby móc Ci doradzić.

Moja aplikacja to uproszczone odzwierciedlenie konta eBay w aplikacji desktopowej. Wszystko jak na razie jest już dla mnie jasne, tylko pozostaje kwestia gdzie umieścić to SDK i jeśli miało by być w Data Access to czy w takim razie muszę generować również Model dla EBay SDK, czy może mogę bezpośrednio z warstwy Presentera odnosić się do warstwy Data Access?

Jak ten temat wygląda w codziennej, zawodowej praktyce?

Jeśli są potrzebne jakieś szczegóły, to oczywiście mogę podać. Chcę od początku dobrze zaprojektować architekturę aplikacji.