Struktur Organisasi Aplikasi PHP yang Pintar?

10

Ada sejuta-dan-satu struktur sistem file yang masuk ke berbagai proyek Open Source yang tersedia. Hal-hal seperti modul, file bahasa, domain, perpustakaan pihak ketiga, migrasi, internasionalisasi, cadangan, dan syslinks ke bagian lain dari sistem telah memunculkan banyak pendekatan untuk mengatur sistem file proyek.

Sebagai pengembang PHP, saya bertanya-tanya apakah ada jenis standardisasi yang mulai muncul di antara proyek-proyek. Dengan PSR-0 kami akhirnya memiliki standar untuk penamaan dan pemuatan file - tetapi tidak ada yang sepengetahuan saya tentang sisa komponen yang membentuk sistem atau bagaimana mereka dapat ditangani dengan cara yang waras.

Kami berurusan dengan lebih dari sekedar MVC, jadi contoh apa saja dari proyek-proyek besar yang menangani semua hal ini dengan benar?

php  project-management  code-organization  file-structure 
— Xeoncross
sumber
3
Sebagai sesama pengembang PHP, saya tidak akan mengharapkan kewarasan dari komponen PHP
— CamelBlues
2
@CamelBlues Berdasarkan peluang murni yang ada, beberapa pengembang PHP akhirnya harus mengacaukan dan melakukan sesuatu dengan benar.
— Xeoncross
Saya belum melihat sejauh standardisasi. Sampai beberapa tahun terakhir Anda akan memiliki folder untuk hal-hal front-end (js, css) dan kemudian Anda akan memiliki menyertakan atau libs dan kemudian templat atau tema dan hanya itu. Baru-baru ini dengan kerangka kerja MVC mendapatkan popularitas itu semua tidak jelas. Saya akan mengatakan jangan khawatir tentang menggunakan standar untuk saat ini dan tetap jelas apa yang terjadi di mana dalam aplikasi khusus Anda.
— Jason

Jawaban:

3

Sangat tidak mungkin untuk menstandarkan bagaimana proyek harus diletakkan, karena "itu tergantung".

Jika Anda memperkenalkan struktur standar, tetapi beberapa di antaranya tidak relevan dengan persyaratan yang sedang dikembangkan, Anda dapat berakhir dengan kebisingan tambahan yang tidak Anda butuhkan. Demikian pula, jika standar perlu bekerja untuk berbagai proyek, mereka harus memasukkan terlalu banyak skenario yang berbeda.

Tugas kita sebagai pengembang adalah mencari pola dan praktik terbaik dan menerapkannya pada tugas yang ada. Kami menggunakan pengalaman dan keahlian kami untuk memilih struktur sistem file yang tepat untuk proyek yang sedang kami kerjakan.

— Fenton
sumber
+1 Secara keseluruhan saya setuju dengan Anda, ini tentu saja merupakan poin yang valid. Namun, jika Anda menghapus hal-hal di luar bahasa (folder cadangan, skrip cron / build, aset statis, dll.) Dan hanya fokus pada bahasa itu sendiri - saya tidak percaya argumen yang sama dapat dibuat. Bahasa sudah memiliki batasan yang diberlakukan. Mencari tahu bagaimana mengatur semua kelas dan kode kunci Anda sehingga masuk akal untuk setiap proyek adalah tujuan nyata dan dapat dicapai.
— Xeoncross
0

Tampaknya tidak ada banyak upaya standardisasi yang terjadi, dan jujur ​​saja, saya tidak melihat manfaatnya. Hanya ada satu aturan yang harus Anda patuhi, yaitu Anda tidak boleh memiliki hal-hal di bawah dokumen yang tidak termasuk di dalamnya (tindakan pencegahan keamanan dasar).

Selain itu, saya hanya pergi dengan apa yang masuk akal untuk proyek ini.

Jika Anda menggunakan MVC (baik melalui framework atau ad-hoc), maka struktur dasar dengan / model, / views dan / controllers masuk akal. Tetapi bahkan jika Anda tidak, Anda biasanya memiliki semacam lapisan akses data dengan kelas yang memetakan ke entitas data Anda; masuk akal untuk memiliki direktori untuk itu; Anda juga biasanya memiliki banyak kelas logika bisnis dan fungsi utilitas, jadi direktori lain untuk itu; jika Anda menggunakan sistem templat, templat masuk ke direktori lain; dan kemudian Anda mungkin menginginkan direktori 'libraries', tempat Anda meletakkan semua perpustakaan pihak ketiga. (Begitu Anda mencapai titik ini, Anda cukup banyak melakukan MVC).

Jika proyek ini benar-benar besar, itu mungkin dapat dibagi menjadi submodula fungsional; jika submodules cukup independen, masuk akal untuk menggunakannya sebagai tingkat atas Anda, dengan satu direktori tambahan untuk kode umum.

— tammmer
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.