Organizacja plików w serwerze wersji
Definicja aplikacji końcowej jest przechowywana w drzewiastej strukturze katalogów i plików w serwerze wersji (w zależności od konfiguracji środowiska będzie to oznaczało postać fizycznych plików na dysku lub dedykowaną bazę danych). Każdy zdefiniowany w aplikacji formularz, proces, struktura danych czy algorytm lub pakiet przetwarzania to osobny plik w serwerze wersji. Można je nazywać oraz grupować w katalogach dowolnie, bez wpływu na działanie aplikacji – odpowiedni układ katalogów i plików ma jedynie pomóc w organizacji projektu i ułatwić projektantowi aplikacji szybkie dotarcie do definicji, której szuka.
Widok fizyczny
Widok fizyczny, będąc domyślnym widokiem, ukazuje faktyczną organizację plików w serwerze wersji.
Widok typów
Widok typów, to alternatywny widok dostępny po wybraniu opcji zaznaczonej niebieską ramką poniżej, w którym pliki pogrupowane są względem zawartego w nich typu definicji (np. formularza lub procesu).
Dobre praktyki
Właściwa organizacja plików i katalogów jest kluczowa przy pracy nad większymi projektami. Poniżej kilka sugestii, które pomogą w organizacji projektu, tak aby w późniejszych fazach projektu łatwiej było utrzymać porządek.
Odpowiednie nazewnictwo plików i katalogów
- Opracuj słownik pojęć – tak aby nie używać wymiennie różnych słów do nazywania tych samych pojęć (biznesowych i technicznych).
- Określ konwencję nazewniczą – sugerujemy stosowanie tzw. PascalCase, czyli zapisu bez odstępów, każdy wyraz z dużej litery.
- Ustal zasady nadawania nazw:
- Nazwy powinny być krótkie ale w stopniu zapewniającym jednoznacznie określenie co dany plik zawiera.
- Nazwy powinny być łatwo odróżnialne – np. kolejne warianty formularza do edycji podmiotu nie powinny się nazywać SubjectDetails1.form, SubjectDetails2.form, SubjectDetails3.form
- Nazwy nie powinny zawierać w sobie typu pliku, ponieważ jest on zawarty w rozszerzeniu, tj. zamiast SubjectForm.form wystarczy używać Subject.form
- Nazwy nie powinny zawierać żadnych znaków specjalnych ani diakrytycznych (dozwolone są tylko małe i duże litery z alfabetu łacińskiego oraz cyfry).
- Nazwy powinny być czytelne – tak aby można było się nimi łatwo posługiwać podczas rozmowy.
- Nazwy reprezentujące struktury danych powinny być w liczbie pojedynczej (Client.edmx zamiast Clients.edmx).
- W przypadku struktur danych warto rozważyć stosowanie wspólnego przedrostka biznesowego dla wszystkich struktur, które stanowią definicję jednego obiektu (np. User.edmx, UserAddress.edmx, UserAccount.edmx) – nazwy te domyślnie przekładają się bezpośrednio na nazwy tabel w bazie danych. Zastosowanie tej konwencji ułatwia późniejszą pracę z wykorzystaniem SQL.
Podział na obiekty i funkcjonalności
- Określ z jakich elementów biznesowych będzie zbudowana aplikacja, poszczególnym obiektom powinny odpowiadać główne katalogi - ( typu katalogi: Struktury danych, Listy , Formularze, itp).
- Podkatalogi odpowiadać mogą grupom (zamkniętych) funkcjonalności systemu np. pliki składające się na definicję całego ekranu wraz z wykorzystywaną przez niego logiką biznesową.
Dekompozycja
- Powtarzające się elementy w różnych definicjach umieszczaj w osobnych plikach – tak aby można było je wykorzystywać wielokrotnie.
- Złożone definicje warto również podzielić na mniejsze, aby uzyskać efekt widoku od ogółu do szczegółu.