Struktura pakietu dla projektu Java?

Jakie są najlepsze praktyki dotyczące konfigurowania struktur pakietów w aplikacji internetowej Java?

Jak skonfigurowałbyś swój src, kod testu jednostkowego itp.?

Możesz naśladować standardowy układ projektu Mavena . Nie musisz faktycznie używać mavena, ale ułatwiłoby to przejście w przyszłości (w razie potrzeby). Ponadto inni programiści będą przyzwyczajeni do oglądania tego układu, ponieważ wiele projektów open source jest ułożonych w ten sposób,

Istnieje kilka istniejących zasobów, które możesz sprawdzić:

1. Prawidłowo spakuj swoje klasy Java
2. Architektura wiosna 2.5
3. Samouczek Java - nazywanie pakietu
4. Konwencje nazewnictwa słońca

Jeśli chodzi o to, co jest warte, moje własne osobiste wytyczne, których zwykle używam, są następujące:

1. Zacznij od domeny odwrotnej, np. „Com.mojafirma”.
2. Użyj nazwy produktu, np. „Myproduct”. W niektórych przypadkach mam zwykle wspólne opakowania, które nie należą do określonego produktu. Zostałyby one podzielone na kategorie według funkcjonalności tych typowych klas, np. „Io”, „util”, „ui” itp.
3. Po tym staje się bardziej swobodny. Zwykle grupuję według projektu, obszaru funkcjonalności, wdrożenia itp. Na przykład mogę mieć „projekt1”, „projekt2”, „ui”, „klient” itp.

Kilka innych punktów:

1. W projektach, nad którymi pracowałem, dość często nazwy pakietów pochodzą z dokumentacji projektowej. Zwykle produkty są już podzielone na obszary funkcjonalności lub przeznaczenia.
2. Nie stresuj się zbytnio umieszczaniem od razu wspólnych funkcji do wyższych pakietów. Poczekaj, aż pojawi się potrzeba w różnych projektach, produktach itp., A następnie dokonaj refaktoryzacji.
3. Obserwuj zależności między pakietami. Nie wszystkie są złe, ale może to oznaczać ścisłe powiązanie między tym, co może być oddzielnymi jednostkami. Istnieją narzędzia, które pomogą Ci to śledzić.

Sugerowałbym tworzenie struktury pakietu według funkcji, a nie warstwy implementacji. Dobry opis to praktyki Java: pakuj według funkcji, a nie warstwy

Zwykle lubię mieć:

• bin (pliki binarne)
• doc (dokumenty)
• inf (informacje)
• lib (biblioteki)
• res (zasoby)
• src (źródło)
• tst (test)

Można to uznać za niekonwencjonalne, ale uważam, że to bardzo fajny sposób na porządkowanie rzeczy.

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

Sposób, w jaki zwykle mam hierarchię folderów

• Nazwa Projektu
  • src
  • kosz
  • testy
  • libs
  • dokumenty

Innym sposobem jest rozdzielenie interfejsów API, usług i jednostek na różne pakiety.