it-swarm.com.de

Ordner nach Typ oder Ordner nach Funktion

Ich benutze einen AngularJS Style Guide. In diesem Handbuch gibt es einen Stil namens folder-by-feature, Anstatt von folder-by-type, und ich bin eigentlich neugierig, was der beste Ansatz ist (in diesem Beispiel für Java)

Angenommen, ich habe eine Anwendung, mit der ich Benutzer und Haustiere mithilfe von Diensten, Controllern, Repositorys und natürlich Domänenobjekten abrufen kann.

Unter Verwendung der Ordner-für -...-Stile haben wir zwei Optionen für unsere Verpackungsstruktur:

1. Ordner nach Typ

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. Ordner für Feature

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

Was wäre ein guter Ansatz und was sind die Argumente dafür?

63
Jelle

Ordner für Typ funktioniert nur bei kleinen Projekten. Ordner für Funktion ist in den meisten Fällen überlegen.

Ordner für Typ ist in Ordnung, wenn Sie nur eine kleine Anzahl von Dateien haben (sagen wir unter 10 pro Typ). Sobald Sie mehrere Komponenten in Ihrem Projekt erhalten, alle mit mehreren Dateien desselben Typs, ist es sehr schwierig, die tatsächlich gesuchte Datei zu finden.

Daher ist Ordner für Funktion aufgrund seiner Skalierbarkeit besser. Wenn Sie jedoch nach Funktionen ordnen, verlieren Sie am Ende Informationen über den Komponententyp, den eine Datei darstellt (weil sie sich beispielsweise nicht mehr in einem controller -Ordner befindet), sodass auch dies verwirrend wird. Hierfür gibt es zwei einfache Lösungen.

Erstens können Sie sich an gängige Namenskonventionen halten, die eine Typizität des Dateinamens implizieren. Zum Beispiel hat John Papas populärer AngularJS Style Guide Folgendes:

Benennungsrichtlinien

  • Verwenden Sie konsistente Namen für alle Komponenten, die einem Muster folgen, das die Funktion der Komponente und dann (optional) ihren Typ beschreibt. Meine
    empfohlenes Muster ist feature.type.js. Für die meisten gibt es 2 Namen
    Vermögenswerte:

    • der Dateiname (avengers.controller.js)
    • der registrierte Komponentenname mit Angular (AvengersController)

Zweitens können Sie Ordner-nach-Typ- und Ordner-nach-Feature-Stile zu Ordner-nach-Feature-nach-Typ kombinieren:

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

Dies hat wirklich nichts mit der fraglichen Technologie zu tun, es sei denn, Sie verwenden ein Framework, das Ihnen im Rahmen eines Konventionskonfigurationsansatzes Ordner für Typ aufzwingt.

Persönlich bin ich der festen Überzeugung, dass Ordner für Funktion weit überlegen ist und überall so oft wie möglich verwendet werden sollte. Es gruppiert Klassen, die tatsächlich zusammenarbeiten, während Ordner nach Typ nur etwas dupliziert, das normalerweise bereits im Klassennamen vorhanden ist.

26

Das Arbeiten mit packages-by-feature zeichnet sich durch hohe Modularität und Kohäsion aus. Es ermöglicht uns, mit dem Umfang der Komponenten zu spielen. Zum Beispiel können wir Zugriffsmodifikatoren verwenden, um LoD und Abhängigkeitsinversion für Integrationen oder/und Erweiterungen zu erzwingen.

Andere Gründe sind:

  • Einfachere Code-Navigation
  • Eine höhere Abstraktionsebene
  • Bereiche minimieren (Grenzkontexte)
  • Vertikale Modularisierung

Folder-by-Layer setzt zu viel Wert auf die Implementierungsdetails , (wie @David erwähnt), was nicht zu viel über die Anwendung aussagt, an der wir arbeiten . Im Gegensatz zu package-by-feature fördert package-by-layer die horizontale Modularisierung. Diese Art der Modularisierung macht das Arbeiten mit Querschnittskomponenten schwierig und mühsam.

Schließlich gibt es noch eine dritte Option. " Paket nach Komponente ", was nach den Worten von Onkel Bob besser mit seinem Paketprinzipien übereinstimmt. Ob Onkels Bob-Meinung wichtig ist oder nicht, überlasse ich Ihnen die Entscheidung. Ich finde es interessant, da diese Konvention mit seiner sauberen Architektur übereinstimmt, die ich mag.

17
Laiv