Beberapa organisasi kode aplikasi Zend


10

Selama setahun terakhir saya telah mengerjakan serangkaian aplikasi yang semuanya didasarkan pada kerangka kerja Zend dan berpusat pada logika bisnis yang kompleks yang semua aplikasi harus memiliki akses ke bahkan jika mereka tidak menggunakan semua (lebih mudah daripada memiliki beberapa folder perpustakaan untuk masing-masing aplikasi karena mereka semua terhubung bersama dengan pusat bersama).

Tanpa membahas lebih detail tentang apa proyek tersebut secara spesifik, saya mencari beberapa masukan (karena saya mengerjakan proyek sendiri) tentang bagaimana saya telah "mengelompokkan" kode saya. Saya telah mencoba untuk membagi semuanya sedemikian rupa sehingga menghilangkan ketergantungan sebanyak mungkin.

Saya berusaha menjaganya agar tetap terpisah seperti yang saya dapat secara logis, jadi dalam waktu 12 bulan ketika waktu saya habis, orang lain yang masuk tidak akan mengalami masalah dalam memperluas apa yang telah saya hasilkan.

Contoh struktur:

applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)

applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\ 
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)

applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)

applicationStorage\Tests\ (contains PHP unit tests)

applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)

(Catatan: folder Modul, Konfigurasi, Tata Letak, dan ZendExtended digandakan di setiap folder aplikasi; tetapi saya telah menghapusnya karena tidak diperlukan untuk keperluan saya.)

Untuk pustaka ini berisi semua kode "universal". Kerangka kerja Zend adalah jantung dari semua aplikasi, tetapi saya ingin logika bisnis saya menjadi Zend-framework-independent. Semua antarmuka model dan mapper tidak memiliki referensi publik ke Zend_Db tetapi sebenarnya membungkusnya secara pribadi.

Jadi harapan saya adalah bahwa di masa depan saya akan dapat menulis ulang pemetaan dan dbtabel (berisi Models_DbTable_Abstrak yang meluas Zend_Db_Table_Abstract) untuk memisahkan logika bisnis saya dari kerangka Zend jika saya ingin memindahkan logika bisnis (layanan) ke suatu lingkungan kerangka non-Zend (mungkin beberapa kerangka kerja PHP lainnya).

Dengan menggunakan serviceLocator dan mendaftarkan layanan yang diperlukan dalam bootstrap setiap aplikasi, saya dapat menggunakan versi berbeda dari layanan yang sama tergantung pada permintaan dan aplikasi mana yang sedang diakses.

Contoh: semua aplikasi eksternal akan memiliki service_auth_External mengimplementasikan service_auth_Interface terdaftar.

Sama dengan aplikasi internal dengan Service_Auth_Internal mengimplementasikan service_auth_Interface Service_Locator :: getService ('Auth').

Saya khawatir saya mungkin kehilangan beberapa kemungkinan masalah dengan ini.

Satu saya setengah berpikir tentang adalah file config.ini untuk semua eksternal, kemudian aplikasi config.ini terpisah menimpa atau menambahkan ke config.ini eksternal global.

Jika ada yang punya saran saya akan sangat menghargai.

Saya telah menggunakan contextswitching untuk fungsi AJAX dalam aplikasi individual, tetapi ada kemungkinan besar baik eksternal maupun internal akan mendapatkan layanan web yang dibuat untuk mereka. Sekali lagi, ini akan dipisahkan karena otorisasi dan berbagai layanan yang tersedia.

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice

Jawaban:


1

Pada akhirnya, beberapa kode akan spesifik untuk "logika bisnis" aplikasi Anda, dan beberapa lainnya adalah "kode perpustakaan". Misalnya, sesuatu yang memvalidasi input formulir umumnya dapat dianggap sebagai "pustaka", sedangkan sesuatu yang membantu Anda menghitung penawaran yang tersedia untuk klien X dalam bulan tertentu jelas "logika bisnis".

Ini lebih merupakan masalah kontrol versi, dan ada banyak cara Anda bisa menguliti kucing khusus ini. Alat-alat seperti Maven (dan sampai tingkat tertentu Phing / Ant) dibangun untuk merakit aplikasi dari berbagai sumber yang berbeda - berdasarkan pada beberapa jenis file konfigurasi eksternal (umumnya XML). Ini berarti Anda dapat mempertahankan repo yang terpisah untuk kode perpustakaan dan mengimpornya ke dalam Aplikasi X jika Anda membutuhkannya.

Jika Anda memiliki kendali atas host Anda, maka Anda dapat berpikir tentang memindahkan barang-barang perpustakaan ke jalur sertakan - dan mempertahankannya sebagai proyek jangka panjang yang terpisah.

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.