Folder-by-type atau Folder-by-feature

Saya menggunakan panduan gaya AngularJS. Di dalam panduan ini ada gaya yang disebut folder-by-feature, alih-alih folder-by-type, dan saya sebenarnya penasaran apa pendekatan terbaik (dalam contoh ini untuk Jawa)

Katakanlah saya memiliki aplikasi tempat saya dapat mengambil Users & Pets, menggunakan layanan, pengontrol, repositori dan objek domain ofcourse.

Mengambil gaya folder-by -....., kami memiliki dua opsi untuk struktur pengemasan kami:

1. Jenis folder

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-by-fitur

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

Apa yang akan menjadi pendekatan yang baik, dan apa argumen untuk melakukannya?

project-structure packages

— Jelle
sumber

Kemungkinan duplikat Mengapa semua orang menempatkan pengontrol di satu folder dan tampilan di folder lain?

— RubberDuck

Saya tidak tahu @Laiv. Apakah bahasa / kerangka kerja benar-benar memengaruhi jawaban? Apapun, pertanyaan lain tentu relevan.

— RubberDuck

Maka saya harus mengedit jawaban saya. Dan ya, itu adalah duplikat yang mungkin

— Laiv

Saya tidak pernah mengerti manfaat folder-per-tipe. Jika saya bekerja pada tiket yang berkaitan dengan fitur Pet, saya mungkin akan mendapat manfaat dari lokalitas Pet, controller, repositori, dan layanan. Dalam situasi apa saya akan membutuhkan semua pengontrol, tetapi bukan dari pandangan, repo atau layanan?

— Alexander

Sepertinya tidak ada yang menyebutkan bahwa paket di Java bukan hanya folder; mereka juga memengaruhi akses untuk kelas-kelas yang ada. Untuk alasan ini, package-by-layer / type sebenarnya dapat memberikan beberapa nilai semantik di Java.

— Angus Goldsmith

Jawaban:

Folder-per-tipe hanya berfungsi pada proyek skala kecil. Folder-by-feature lebih unggul di sebagian besar kasus.

Folder-by-type ok ketika Anda hanya memiliki sejumlah kecil file (di bawah 10 per jenis katakanlah). Segera setelah Anda mendapatkan banyak komponen dalam proyek Anda, semua dengan banyak file dari jenis yang sama, akan sangat sulit untuk menemukan file yang sebenarnya Anda cari.

Oleh karena itu, folder-by-fitur lebih baik karena skalabilitasnya. Namun jika Anda folder oleh fitur Anda akhirnya kehilangan informasi tentang jenis komponen file mewakili (karena tidak lagi dalam controllerfolder katakanlah), jadi ini juga menjadi membingungkan. Ada 2 solusi sederhana untuk ini.

Pertama, Anda dapat mematuhi konvensi penamaan umum yang menyiratkan ketelitian dalam nama file. Misalnya panduan gaya AngularJS populer John Papa memiliki yang berikut:

Pedoman Penamaan

Gunakan nama yang konsisten untuk semua komponen mengikuti pola yang menggambarkan fitur komponen lalu (secara opsional) tipenya.
Pola yang saya rekomendasikan adalah feature.type.js. Ada 2 nama untuk sebagian besar
aset:

nama file (avengers.controller.js)

nama komponen terdaftar dengan Angular (AvengersController)

Kedua, Anda dapat menggabungkan gaya folder-per-jenis dan folder-per-fitur ke dalam folder-per-fitur-menurut-jenis:

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

— Pasang kembali Monica
sumber

Panduan gaya johnpapa adalah persis yang saya pura-pura tentang :-)

— Jelle

Beberapa kali (lebih sering dari yang kita pikirkan) kita menambahkan terlalu rumit untuk hal-hal yang seharusnya mudah. Penamaan dan pengemasan adalah beberapa dari hal-hal ini. Saran terbaik adalah tetap sederhana. Menggabungkan keduanya memiliki kelebihan dan kekurangan dari kedua pendekatan tersebut.

— Laiv

@ Longv Pada contoh yang saya berikan, saya setuju dengan pembunuhan yang berlebihan, tetapi dalam sebagian besar kasus bisnis nyata saya di mana setiap jenis-folder dapat dengan mudah memiliki 10-20 file, saya pikir ini sangat berguna karena keseluruhan fitur-folder akan memiliki urutan 50 file sebaliknya.

— Pasang kembali Monica

memalsukan, terima kasih iPhone koreksi otomatis! Maksud saya 'berbicara'.

— Jelle

@Chaotic Contoh ini terlalu sepele untuk memulai pembicaraan spesifik, tetapi dalam kasus seperti itu di mana Anda memiliki potongan yang digunakan di beberapa komponen, maka itu mungkin harus menjadi komponen sendiri yang bergantung pada komponen lain.

— Reinstate Monica

Ini benar-benar tidak ada hubungannya dengan teknologi yang dimaksud, kecuali jika Anda menggunakan kerangka kerja yang memaksa folder-jenis pada Anda sebagai bagian dari pendekatan konvensi-konfigurasi.

Secara pribadi, saya sangat berpendapat, bahwa folder-by-fitur jauh lebih unggul dan harus digunakan di mana-mana sebanyak mungkin. Ini mengelompokkan kelas-kelas yang benar-benar bekerja bersama, sedangkan folder-dengan-tipe hanya menduplikasi sesuatu yang biasanya sudah ada dalam nama kelas.

— Michael Borgwardt
sumber

Saya akan menambahkan bahwa di folder-oleh-fitur membuat lebih mudah untuk bermain dengan kelas dan metode cakupan (dilindungi, paket, ...).

— Laiv

Untuk proyek yang lebih kecil, Anda mungkin hanya memiliki satu fitur. Jauh lebih mudah untuk mengatur berdasarkan jenis skenario itu.

— aaaaaa

Sebagai contoh, Grails memang memaksa folder-menurut-jenis untuk domain, pengontrol, layanan, dll.

— tylerwal

Bekerja dengan paket-per-fitur menonjol dalam modularitas dan kohesi yang tinggi . Hal ini memungkinkan kita untuk bermain dengan ruang lingkup komponen. Sebagai contoh, kita dapat menggunakan pengubah akses untuk menegakkan LoD dan inversi dependensi untuk integrasi atau ekstensi.

Alasan lainnya adalah:

Navigasi kode yang lebih mudah
Tingkat abstraksi yang lebih tinggi
Minimalkan cakupan (pembatas konteks)
Modularisasi vertikal

Folder-by-layer memberi terlalu banyak penekanan pada detail implementasi , (seperti yang disebutkan @David) apa yang tidak banyak bercerita tentang aplikasi yang sedang kami kerjakan. Tidak seperti package-by-feature , package-by-layer mendorong modularisasi horizontal. Modularisasi semacam ini membuat bekerja dengan komponen lintas sektor menjadi sulit dan membosankan.

Akhirnya, ada opsi ke-3. " Paket demi komponen " yang, dalam kata-kata Paman Bob, tampaknya lebih selaras dengan prinsip-prinsip paketnya . Jika pendapat Paman Bob penting atau tidak, saya serahkan pada Anda untuk memutuskan. Saya merasa menarik karena konvensi ini selaras dengan Arsitektur Bersih-nya, yang saya suka.

— Laiv
sumber