Bagaimana Anda mengatur kerangka kerja MVC Anda saat mendukung modul / plugin? [Tutup]


17

Ada dua struktur basis kode utama yang saya lihat ketika datang ke kerangka kerja MVC. Masalahnya adalah bahwa mereka berdua tampaknya memiliki bug organisasi yang menyertai mereka.

MVC standar

/controller
/model
/view

Masalah: Tidak ada pemisahan komponen terkait (forum, blog, pengguna, dll.)

MVC modular

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

Memilih sistem berbasis modul membuat Anda memiliki masalah.

  • Nama panjang (Forum_Model_Forum = forum / model / forum.php) (Seperti Zend)
  • Pencarian sistem file menggunakan is_file()untuk menemukan folder mana yang memiliki model forum? (Seperti Kohana)

Apakah ada struktur MVC lain yang berfungsi dengan baik ketika mencoba memisahkan modul yang berbeda? Apakah ada manfaat dari struktur ini yang saya lewatkan?


1
Saya juga ingin menambahkan bahwa saya ingin struktur yang sesuai dengan PSR-0 jadi saya juga dapat menggunakan perpustakaan seperti Zend dan Doktrin jika diperlukan.
Xeoncross

Jawaban:


9

Mencoba:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

Model Anda adalah jantung dari aplikasi Anda. Anda harus mendesain dan mengkodekannya sebagai paket mandiri. Pengontrol hanyalah klien dari model Anda, yang kebetulan menerjemahkan aktivitas pengguna menjadi tindakan untuk model Anda. Tampilan hanyalah salah satu cara khusus untuk menampilkan data dari model Anda. Jika aplikasi Anda tumbuh, Anda dapat melangkah lebih jauh dalam memisahkan klien dari model:

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

Ini harus menjelaskan bahwa Anda dapat memiliki banyak klien, yang semuanya dengan satu atau lain cara, berinteraksi dengan satu model.


+1 karena saya sepenuhnya setuju dengan penjelasan Anda tentang komponen MVC dan bagaimana mereka seharusnya bekerja. Namun, maksud dari modul adalah Anda dapat mengimpor modul yang dibuat oleh pengguna lain sehingga memiliki model di luar jalur modul membuatnya kurang "seret-dan-jatuhkan". Namun, metode Anda sangat masuk akal untuk aplikasi yang tidak menggunakan plugin atau modul eksternal.
Xeoncross

@ Xeoncross itu benar, saya belum benar-benar mempertimbangkan penggunaan kembali di sini. Jika itu persyaratan, Anda memang bisa melangkah lebih jauh dan memiliki misalnya modul 'Pengguna' yang mengelompokkan model Pengguna dengan pengontrolnya, dan modul Blog yang mengelompokkan model BlogPost dan Komentar dengan pengontrolnya. Seperti biasa: itu tergantung pada konteks :-)
Mathias Verraes

2

;)

Saya menemukan struktur terbaik untuk Kerangka MVC / HMVC digabungkan. Untuk utama Anda perlu menggunakan pengendali dasar / model / tampilan ... tetapi untuk masing-masing komponen modul saja ...

Jadi dalam struktur kerangka MVC / HMVC saya terlihat seperti ini:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

Juga jika saya perlu saya menambahkan modul perpustakaan, i18n atau pembantu.

Konvensi penamaan mudah, untuk pengontrol dan model saya menambahkan akhiran _Controller dan _Model. Untuk pengontrol dan model dari modul saya juga menambahkan awalan dengan nama modul, misalnya. Profil pengontrol di modul Pengguna akan dinamai User_Profile_Controller.

Jadi sangat mudah dan cepat untuk menemukan apa yang Anda butuhkan.


1

Masalah: Nama panjang (Forum_Model_Forum)

Penamaan kelas secara sistematis membantu menghindari konflik penamaan antar komponen. Penamaan kelas yang lama sepertinya tidak akan menjatuhkan hukuman kinerja yang berat. Saya menemukan skema penamaan ini agak membantu ketika coding karena mudah untuk melihat apa yang datang dari mana.

pencarian sistem file (folder mana yang memiliki model forum?).

Ini sangat tergantung pada bagaimana sistem telah diimplementasikan, tetapi struktur sistem file biasanya mengikuti konvensi yang memungkinkan akses langsung ke komponen yang benar tanpa pencarian sistem file yang luas.

Berikut ini sebuah contoh, misalkan komponen forum yang akan digunakan:

Info:

  • Komponen-nama: forum
  • Nama pengontrol: indeks

    $ controller_path = BASEDIR. 'modul /'. $ component_name. '/ controller /'. $ controller_name. '.php';

Juga penting untuk dicatat bahwa ada ratusan permintaan sistem file saat mem-boot situs web biasa, jadi menambahkan beberapa tidak akan merugikan.


Sungguh, ujung belakang tidak seperti aplikasi sisi klien yang perlu memulai dengan cepat, mereka dapat mengambil waktu yang dibutuhkan untuk mengkonfigurasi waktu menjalankan dengan benar. Poin bagus.
Patrick Hughes

0

Saya telah bekerja dengan situs web yang dimulai dengan "MVC Standar" pertama, tetapi akhirnya, menjadi "MVC Modular".

Jika Anda melakukan situs web kecil, dan tidak memiliki banyak pengalaman, Anda mungkin ingin memulai dengan "MVC Standar". Jika Anda sudah tahu situs web akan menjadi sangat kompleks dan besar, maka, Anda harus terbiasa dengan "Modular MVC", itu akan sedikit sulit pada awalnya, tetapi, pada akhirnya, Anda akan terbiasa dengan Itu.


0

Saya sebenarnya sedang mengerjakan framework sendiri dan menggunakan kombinasi struktur direktori berbasis-modul dan bentuk bebas. Struktur default saya untuk kode situs menggunakan kerangka kerja adalah:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

Anda juga dapat memiliki folder modul yang tidak terkait dengan pengontrol dan ada satu secara default Core yang digunakan untuk menyimpan templat lebar situs seperti header dan footer. Bagi saya ini memberikan yang terbaik dari kedua dunia. Anda dapat dengan mudah mengetahui di mana pengontrol karena ada satu pengontrol per folder tetapi untuk kelas seperti model Anda tidak perlu mencari di mana file berada di bawah satu direktori (yang juga membuat nama model bersih) .

Cara saya memuat file sedikit berbeda karena saya mengizinkan pengguna untuk mengkonfigurasi direktori berbeda di mana kelas bisa jadi saya parsing direktori awalnya dan menyimpan semua lokasi file kelas dalam file json dan kemudian menggunakannya untuk mencari cepat untuk semua permintaan lainnya (meskipun saya mencari cara untuk meningkatkan ini).


0

Jawabannya telah ditentukan oleh Proposal PSR-0 yang mana semua sistem besar mulai beradaptasi, atau telah mengadopsi sekarang.

Strukturnya adalah:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

Ini berarti tidak ada yang dapat Anda lakukan untuk memperbaiki nama file yang panjang:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

Ini juga berarti Anda harus menggunakan file case campuran bodoh alih-alih semua huruf kecil (jika Anda tidak perpustakaan pihak ketiga tidak akan berfungsi).


0

Solusi Mathiases sangat masuk akal Dan menggunakan struktur foldernya tidak mencegah memiliki konten yang dapat dicolokkan, misalnya menambahkan independen / galeri / bisa terlihat seperti ini

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

Sekarang kita memiliki "model" bersama dan yang independen jika perlu

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.