Korzystam z przewodnika po stylu AngularJS. W tym przewodniku jest styl zwany folder-by-featurezamiast 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?

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 controllerfolderze, 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:

Wskazówki dotyczące nazewnictwa

• Użyj spójnych nazw dla wszystkich komponentów zgodnie ze wzorcem, który opisuje funkcję komponentu, a następnie (opcjonalnie) jego typ. Mój
  zalecany wzór to feature.type.js. Istnieją 2 nazwy większości
  zasobów:

  • nazwa pliku (avengers.controller.js)
  • zarejestrowana nazwa komponentu w Angular (AvengersController)

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:

com.example
├── pet
|   ├── Controllers
│   |   ├── PetController1.java
|   |   └── PetController2.java
|   └── Services
│       ├── PetService1.java
│       └── PetService2.java
├── user
|   ├── Controllers
│   |   ├── UserController1.java
│   |   └── UserController2.java
|   └── Services
│       ├── UserService1.java
│       └── UserService2.java

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.

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:

• Łatwiejsza nawigacja po kodzie
• Wyższy poziom abstrakcji
• Minimalizuj zakresy (konteksty graniczne)
• Modularyzacja pionowa

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ę.