Korzystam z przewodnika po stylu AngularJS. W tym przewodniku jest styl zwany folder-by-feature
zamiast folder-by-type
, i jestem ciekawy, jakie jest najlepsze podejście (w tym przykładzie dla Javy)
Załóżmy, że mam aplikację, w której mogę odzyskiwać użytkowników i zwierzęta, korzystając z usług, kontrolerów, repozytoriów i obiektów domeny oczywiście.
Biorąc pod uwagę style sortowania według, mamy dwie opcje dla naszej struktury opakowania:
1. Folder według typu
com.example
├── domain
│ ├── User.java
│ └── Pet.java
├── controllers
│ ├── UserController.java
│ └── PetController.java
├── repositories
│ ├── UserRepository.java
│ └── PetRepository.java
├── services
│ ├── UserService.java
│ └── PetService.java
│ // and everything else in the project
└── MyApplication.java
2. Folder według funkcji
com.example
├── pet
│ ├── Pet.java
│ ├── PetController.java
│ ├── PetRepository.java
│ └── PetService.java
├── user
│ ├── User.java
│ ├── UserController.java
│ ├── UserRepository.java
│ └── UserService.java
│ // and everything else in the project
└── MyApplication.java
Jakie byłoby dobre podejście i jakie są tego argumenty?
project-structure
packages
Jelle
źródło
źródło
Pet
, kontrolera, repozytorium i usługi. W jakiej sytuacji potrzebowałbym kiedykolwiek wszystkich kontrolerów, ale nie widoków, repozytoriów lub usług?Odpowiedzi:
Folder według typu działa tylko w przypadku małych projektów. Folder według funkcji jest lepszy w większości przypadków.
Sortowanie według typu jest w porządku, gdy masz tylko niewielką liczbę plików (powiedzmy poniżej 10 na typ). Jak tylko pojawi się wiele komponentów w swoim projekcie, wszystkie z wieloma plikami tego samego typu, bardzo trudno jest znaleźć rzeczywisty plik, którego szukasz.
Dlatego funkcja sortowania według folderów jest lepsza ze względu na skalowalność. Jednak jeśli folder według funkcji spowoduje utratę informacji o typie elementu, który reprezentuje plik (ponieważ nie ma go już w
controller
folderze, powiedzmy), to również staje się mylące. Są na to 2 proste rozwiązania.Po pierwsze, możesz przestrzegać typowych konwencji nazewnictwa, które sugerują typowość w nazwie pliku. Na przykład popularny przewodnik po stylu AngularJS Johna Papy ma następujące elementy:
Po drugie, możesz łączyć style folderów według typu i folderów według funkcji w folderze według funkcji według typu:
źródło
To naprawdę nie ma nic wspólnego z omawianą technologią, chyba że użyjesz frameworka, który wymusza na tobie sortowanie według typu w ramach podejścia opartego na konwencjach i konfiguracji.
Osobiście jestem głęboko przekonany, że funkcja sortowania według folderów jest znacznie lepsza i powinna być używana wszędzie, jak to możliwe. Grupuje razem klasy, które faktycznie ze sobą współpracują, podczas gdy folder według typu kopiuje tylko coś, co zwykle jest już obecne w nazwie klasy.
źródło
Praca z pakietami według funkcji wyróżnia się wysoką modułowością i spójnością . Pozwala nam to na zabawę w zakres komponentów. Na przykład możemy użyć modyfikatorów dostępu, aby wymusić LoD i inwersję zależności dla integracji lub rozszerzeń.
Inne powody to:
Folder po warstwie kładzie zbyt duży nacisk na szczegóły implementacji (jak wspomniał @David), co nie mówi zbyt wiele o aplikacji, nad którą pracujemy. W przeciwieństwie do pakiet po funkcji , pakiet po warstwie zachęca do poziomej modularyzacji. Ten rodzaj modularyzacji sprawia, że praca z elementami przekrojowymi jest trudna i uciążliwa.
Wreszcie jest trzecia opcja. „ Pakiet po komponencie ”, który, jak mówi wujek Bob, wydaje się lepiej dostosowany do jego zasad dotyczących pakietów . Jeśli opinia wuja Boba ma znaczenie, czy nie, pozostawiam to tobie do podjęcia decyzji. Uważam to za interesujące, ponieważ konwencja ta jest zgodna z jego Czystą architekturą, którą lubię.
źródło