Apa arsitektur yang baik (rapi) dalam pemrograman situs web sederhana, misalnya buku kontak?


28

Ketika saya membangun situs web sederhana, misalnya buku kontak tempat saya dapat menambah, menghapus, dan memperbarui kontak, saya membuat index.phpfile di mana pengguna, jika dia tidak login, diminta untuk memasukkan kata sandi dan jika dia memasukkan kata sandi yang tepat, dia menetapkan sesi dan dapat melakukan hal-hal tertentu dengan kontak.

Saya punya dua file:

  1. Yang pertama ( contacts.php) adalah agar kode HTML ditampilkan. Di atas kode HTML saya menyertakan file kedua dan membuat kelas.
  2. Yang kedua ( contacts_class.php) berisi semua metode untuk menambah, menghapus dan memperbarui.

Saya pikir tidak apa-apa, tetapi ketika datang untuk mengimplementasikan proyek besar, bagaimana saya harus melakukannya? Apakah saya harus membuat folder untuk setiap halaman dan memasukkan file ke dalamnya (seperti di atas, HTML dan kelas), dan bagaimana saya harus melakukannya? Apa arsitektur yang baik dan rapi untuk membangun proyek-proyek besar yang setiap programmer lain akan mengerti dengan sempurna

Jawaban:


67

Anda mengajukan pertanyaan yang sangat menarik dan mendasar. Pertanyaan mengenai arsitektur proyek skala besar dan organisasi struktur folder (yang merupakan sekunder dari arsitektur).

Saat ini pendekatan yang paling umum untuk membangun arsitektur kerangka CMS adalah penggunaan pola MVC. Ada beberapa artikel bagus tentang membangun kerangka kerja MVC Anda sendiri, salah satunya adalah Membangun Kerangka MVC dengan PHP .

MVC adalah singkatan dari Model, View, Controller. Anda dapat menyebut pendekatan ini apa pun yang Anda suka - MVC, HMVC, MVP. Intinya adalah mengisolasi masing-masing komponen sistem Anda. "Controller" mengambil data dari "Model" dan mengirimkannya ke "View", yang menjadikan HTML final. Anda telah menerapkan "V" di Anda contacts.phpdan "MC" di contacts_class.php. Jadi, Anda telah mengisolasi tampilan dari model dan pengontrol. Sekarang Anda dapat dengan mudah mengubah "Tampilan" Anda dan membiarkan bagian lain tetap utuh.

Saya tidak menyarankan Anda untuk secara membabi buta mengikuti pola MVC, MVP atau apa pun "MV" lainnya. Ini adalah masalah kesesuaian, kemanjuran dan rasa.

Aplikasi situs web dinamis umum dapat mencakup komponen-komponen seperti:

  • Titik masuknya, katakanlah index.php
  • Perpustakaan / kelas pembantu
  • Router permintaan
  • Modul, komponen, atau pengontrol
  • Mesin templat atau mungkin tampilan tunggal

Aplikasi web yang sebenarnya dapat mencakup komponen lain seperti penangan acara, pengirim acara, dan pengait, tetapi ini sebenarnya adalah nuansa. Baiklah, izinkan saya menyajikannya sebagaimana saya ingin menyajikannya:

Diagram operasi rutin

Rutin operasi operasi umum sebagai berikut:

  1. Permintaan browser dikirim langsung ke executable / script titik masuk ( index.php).
  2. Script entry point memuat pustaka helper, kelas dan melakukan beberapa inisialisasi lebih lanjut dari lingkungan pemrograman kami.
  3. URL diteruskan ke instance router permintaan. Langkah ini dapat menjadi bagian dari langkah 2.
  4. Router permintaan mem-parsing URL dan mengirimkan operasi ke komponen, modul, atau pengontrol tertentu.
  5. Komponen (atau pengontrol) memproses permintaan yang dirutekan dan mengirimkan data ke tampilan untuk diberikan.

Struktur folder proyek yang sesuai ditunjukkan pada diagram.

Saya akan menyarankan Anda untuk menyelidiki bagaimana kerangka kerja lainnya diterapkan. CMS / framework yang direkomendasikan untuk memulai adalah CodeIgniter, OpenCart, Joomla 1.5 dan Tango CMS.


3
Apa yang Anda gunakan untuk membuat gambar itu? Jawaban Hebat!
Mark Tomlin

3
Terima kasih atas evaluasi positif jawaban saya! Saya sangat menghargai itu! Jawaban ini sepenuhnya hasil analisis dari berbagai kerangka kerja aplikasi web open source, yang saya lakukan sebelumnya untuk diri saya sendiri. Bagi mereka yang tertarik pada bagaimana gambar itu dibuat dan perangkat lunak yang digunakan, gambar itu dibuat menggunakan Inkscape 0.48 dan GIMP 2.6.10. Tidak masalah dengan itu. Cukup gunakan dua layer: satu untuk persegi panjang dengan teks, satu untuk bayangan (persegi panjang hitam kabur). Saya kira Anda mengerti sisanya?

Satu pertanyaan, mengapa Anda memisahkan pengontrol 'kontak' menjadi 3 file. Bukankah lebih bersih untuk menggabungkan mereka menjadi satu kontak. Php. Yang harus Anda lakukan adalah memasukkan parameter aksi dari router. Hal yang sama dapat dikatakan untuk tampilan 'kontak' kecuali jika tampilan Anda mencampur templating dan logika menjadi satu file untuk setiap tindakan. Saya tidak melakukan banyak dev di PHP (saya bekerja sebagian besar di Python) tapi saya harap tidak semua kerangka menggunakan pendekatan ini. Kalau tidak, +1 untuk langgan yang bagus.
Evan Plaice

2

Untuk mendapatkan gagasan tentang pertanyaan apa yang harus diajukan dan solusi apa yang tersedia, saya merekomendasikan buku Patterns of Enterprise Application Architecture karya Martin Fowler. Anda bisa mendapatkan gagasan tentang apa yang ada di buku dengan membaca situs web-nya

Perlu diketahui bahwa buku ini sudah cukup tua (di tanah IT) tetapi banyak prinsip yang masih berlaku atau Anda harus mempelajarinya. (Apakah itu masuk akal?)

(Perangkat Lunak) Arsitektur adalah subjek yang sangat luas, jangan berharap peluru perak tetapi selalu lebih banyak pertanyaan dan keraguan sampai waktu dan uang habis dan Anda harus tetap dengan solusi terbaik sejauh ini.


2

Pertama-tama, lihatlah proyek yang dikembangkan dengan baik. Wordpress adalah contoh struktur kode yang sangat rapi: sederhana untuk dipahami tetapi menawarkan banyak "plug". Jadi wordpress mudah dibuat melalui "plug in".

Kedua, cara yang sangat mudah untuk memeriksa arsitektur Anda adalah mencoba menulis unit test. Misalnya jika kelas "Kartu Deck" memiliki metode "shuffle ()", Anda harus dapat membuat Kartu Deck dengan ukuran yang telah ditentukan (yaitu 5 kartu 1,2,3,4,5), panggil shuffle dan verifikasi dalam sebuah cara mudah hasilnya (id 1,4,2,5,3)

Anda harus dapat melakukannya tanpa membuat instan seluruh kelas proyek, dan tes harus sangat bersih untuk dibaca.

Jika Anda tidak bisa melakukannya, Anda harus menambahkan lapisan di antara kelas, merestrukturisasi mereka, sampai Anda mendapatkan cara mudah untuk melakukannya.

Kemudian ulangi langkah ini untuk semua kelas inti dari proyek Anda.

Last but not least: architecure yang bagus bisa jadi "malas" pada kelas yang tidak terlalu inti (ini masalah ekonomi: barang yang dirancang dengan sangat baik harganya terlalu mahal di dunia nyata).


1

Arsitektur yang bagus untuk proyek skala besar adalah MVC (Model View Controller): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80809393controller

Namun, apakah pemrogram lain akan memahaminya adalah masalah yang sama sekali berbeda. MVC bisa menjadi kompleks dan kadang-kadang berlebihan untuk proyek-proyek kecil. Salah satu manfaatnya adalah timbangannya mudah.


Itu sebuah pola, bukan arsitektur.
halfdan

Saya berpendapat bahwa mereka satu dalam hal yang sama. Bagaimana Anda membedakan keduanya? Baca juga baris pertama halaman Wikipedia yang saya posting.
Chris Laplante

1
Dari pengalaman saya, MVC tidak rumit dan sangat berguna dalam proyek-proyek kecil juga. Namun saya setuju, itu adalah pola dan bukan keseluruhan arsitektur.
Danny Varod

MVC adalah pola, bukan arsitektur per se, tetapi dapat dianggap sebagai bagian dari arsitektur. Dan ternyata tidak sesulit itu.

1

Jika saya memahami pertanyaan Anda dengan benar, Anda berbicara tentang struktur folder proyek dan pada dasarnya bukan arsitektur. Jika pemahaman saya benar, baca terus; edit pertanyaan Anda atau berikan komentar dan saya akan mengedit jawaban saya.

Saat merancang aplikasi, setelah menjawab beberapa pertanyaan dasar seperti (apa? Dan kepada siapa?), Kita perlu Mengidentifikasi komponen dan mengklasifikasikannya berdasarkan fungsionalitas \ tanggung jawab. Ada dua cara utama yang saya tahu. Anda dapat mengklasifikasikan komponen berdasarkan, menggunakan kasus yang mereka tangani (seperti login, mencari dll) atau mengklasifikasikan berdasarkan Sumber Daya (Objek ..). Cara pertama disebut Activity oriented dan yang kedua disebut Resource Oriented. Secara tradisional sebagian besar aplikasi mengklasifikasikan komponen berdasarkan Kegiatan (karena desainer menemukannya, mudah saat mentransfer dari domain masalah ke domain solusi). Tetapi saya ngelantur.

Setelah klasifikasi komponen diidentifikasi, maka kita perlu mengidentifikasi klasifikasi berdasarkan Tiers. Aplikasi web tipikal akan memiliki Tier Tampilan, Tier Model, dan Tier Kontroler (MVC). Tentu saja mungkin ada aplikasi yang lebih kompleks juga. (sebagian besar aplikasi dunia nyata lebih kompleks daripada langsung seperti ini).

Setelah Mengidentifikasi dua taksonomi ini, saya akan membuat folder tingkat atas Mengidentifikasi setiap Tingkatan. (UI, Pengendali, Layanan, Utilitas dll). Di bawah setiap folder tingkat tinggi, saya akan membuat folder anak berdasarkan Fungsionalitas atau Sumber Daya (Proyek - / EditProyek - / SearchProject dll). Klasifikasi fungsional idealnya akan bertingkat.


Saya belum membahas lebih jauh perbedaan antara Berorientasi Sumber Daya dan Perancangan Berorientasi Aktivitas. Selain ngelantur, saya tidak terlalu yakin dengan pertanyaan itu. Tetapi secara pribadi dalam hal kejelasan desain (betapa mudahnya pengembang baru dapat memahami komponen dan desain yang mendasarinya), Arsitektur Berorientasi Sumber Daya lebih baik. Dengan hanya melihat ke hierarki folder, pengembang dapat memahami seluruh sumber daya yang berpartisipasi dan sub sumber daya dan operasi pada setiap sumber daya juga seragam.

1

Ada arsitektur yang baik dan arsitektur yang buruk, namun tidak ada peluru perak. Arsitektur harus disesuaikan dengan persyaratan saat ini dan sangat mungkin di masa depan.

Pedoman yang baik adalah, pastikan setiap bagian dari aplikasi dapat diubah dengan efek minimal pada bagian-bagian lain dan bahwa setiap bagian memiliki unit cakupan penuh otomatis dan tes integrasi.


1

Arsitektur adalah tentang memastikan Anda dapat terus berkembang dalam jangka panjang. Untuk aplikasi yang lebih besar, ini termasuk membuat trade-off antara membuat hal-hal independen sehingga banyak orang dapat bekerja secara bersamaan dan menghindari duplikasi (KERING) sehingga proyek dapat tetap gesit. Proyek-proyek PHP cenderung berfokus pada hal-hal yang independen dan memiliki banyak duplikasi.

Untuk mendapatkan perasaan yang baik untuk posisi ekstrem lainnya, lihat Seaside


1

Jika Anda tidak tahu bagaimana cara menyusun proyek besar Anda harus meminjam desain / arsitektur orang lain dengan menggunakan salah satu dari beberapa Kerangka PHP yang baik. Saya akan merekomendasikan CakePHP, CodeIgniter, atau Symfony. Semua ini menerapkan patten Model, View, Controller, MVC yang berfungsi baik dalam pengembangan web, semuanya cukup ringan dan mudah dipelajari.

Setelah Anda mengenal salah satu kerangka kerja ini Anda mungkin berada dalam posisi untuk merancang struktur Anda sendiri untuk proyek khusus Anda, tetapi jika Anda baru memulai, saya akan berdiri pada pekerjaan orang lain vs menciptakan kembali roda.


0

MVC adalah arsitektur yang paling umum digunakan, yang terbukti dapat mengatasi sebagian besar masalah. Arsitektur yang baik akan memiliki fitur-fitur berikut (dan banyak lagi, orcourse)

  1. Ini dapat diuji unit
  2. Pemisahan masalah
  3. Banyak orang akan dapat mengerjakannya tanpa tabrakan.
  4. Itu dapat diperpanjang tanpa banyak masalah
  5. Itu bisa scalable. Ketika sampai pada proyek-proyek besar, skalabilitas akan menjadi perhatian utama. Kerangka kerja Kohana Checkout , yang ditulis dengan baik dan dapat diskalakan dengan sangat baik

0

sebelum Anda menulis kode produksi, perlu waktu 2 minggu (malam :) dan baca buku ini. Ini akan mengubah pikiran Anda untuk waktu yang lama tentang arsitektur pemrograman, praktik dan pengemasan.

Prinsip, Pola, dan Praktek Agile C # oleh Prentice Hall

Contohnya dalam C # tetapi mereka mudah dibaca itu bukan tentang bagaimana menulis sintaks kode yang benar itu adalah tentang bagaimana berpikir sebagai seorang programmer.

Saya berjanji Anda akan menyimpannya di tempat Anda yang paling mudah diakses di pc Anda dan Anda akan kagum bahwa Anda telah memprogram tanpa menyadarinya. Ini akan mengubah pemikiran Anda.

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.