ORM, DOCTRINE PADA SYMFONY FRAMEWORK

NOTE : tulisan ini dengan asumsi pembaca sudah mengerti symfony framework

ketika awal membuat program elfa di kantor kami
RIZKY menyarankan dengan gigih dan berapi api untuk tidak menggunakan ORM, atau wrapper istilahnya mysql er ...

tapi aku tetep kekeuh menggunakan ORM dan doctrine yang terpilih menjadi ORM. alasanku sebenarnya simple saja, kalo mau menggunakan SP ada beberapa masalah berikut :

1. SDM untuk masalah sp sp an ini belum cukup banyak di kantor kamu, dan untuk elfa ini SDM yang terlibat mencar mencar, artinya gak cuman megang elday tok, kecuali tika yang saat ini idle terus gw pinjam, menjadi query er juga tapi tentu saja dengan doctrine
2. Berbeda dengan risma, om rq bisa terus memonitor sp sp nya dia, melakukan testing, hingga menemukan beberapa bug punya nya ucil. Nah untuk elfa ini aku khawatir gak bisa di monitor sampai sedetail itu
3. Ada kondisi SDM harus bertukar tukar. miftah dan sulis masih harus di sicerdas, jika suatu saat kondisi terburuk katakan lah aku yang harus menggantikan, aku lebih suka mendebug function di model layer php daripada harus mendebug SP. karena tools profiling di doctrine ini cukup mendukung untuk melakukan debuging. Dan aku yakin SDM yang available sekarang lebih suka mendebugnya di level PHP :)
   

dan setelah membaca blog dari mysql performance blog, ada yang menyarankan menggunakan "wrapper PDO", karena tools untuk profiling nya cukup banyak, mulai dari log query , execution time, terus penanganan DIRTY QUERY, dan inputan untuk menghindari mysql injection...., doctrine adalah ORM yang menggunakan lib pdo

Dengan kata lain DOCTRINE akan mengeliminir kesalahan kesalahan programer untuk melakuan DIRTY QUERY ... dan memudahkan debuging dengan ada nya profiling toolsnya ... dan bukan hanya itu kita juga bisa melakukan unit testing untuk masing masing function nya. Ini ... yang akan aku bahas di tulisan ini juga

Bagiku ada cons dan pros nya menggunakan ORM atau TIDAK, business layer di DBMS atau di PHP. tapi untuk memudahkan monitoring kita harus memilih salah satu, jangan pakek dua dua nya, manage nya bakal ribet ... kalo makek ORM dan business layernya di PHP, ya gunakan lah itu terus sebisa mungkin di project itu jangan di campur dengan menulis logic di DBMS nya
kalo udah nulis logic di DBMS nya, ya tulislah logic nya di DBMS nya , jangan di campur nulis logic di PHP nya ...

untuk program elfa ini, miftah dan tika benar benar aku paksa menuliskan logic nya pada business layer nya yang sudah disediakan doctrine. Ini habit coding yang harus di galakkan ...

JADI kita punya 2 miniatur project di sini, elfa dengan PHP business logic, dan RISMA dengan DBMS business logic.

comment ku selama ini untuk make ORM ... gak sempurna , masih banyak kekurangan di sana sini .. dan karena ORM ini diharapkan mampu kompatibel dengan berbagai DBMS harga yang harus di bayar adalah kita gak bisa menggunakan function specific dari DBMS ... , tapi Doctrine versi terakhir sudah bisa , dengan jalan kita ngasih flag dulu, kalo kita mau makek MYSQL oleh karena itu ijinkan untuk menggunakan function specific dari MYSQL ...gitu... akhirnya bisa di panggil function nya itu..

Untuk doctrine ...
ada 3 macam data yang bisa kita buat di fixtures.yml

1. initiate data, ini adalah data inisialisasi yang harus di isikan agar sistem berjalan
2. test data, ketika kita ingin melakukan unit testing pada function logic kita, tentu saja kita butuh tabel kita itu kosong untuk kemudian di isi data testing kemudian di lakukan unit testing , pasti ada data yang ke insert, ke update, ke delete. pada tiap automated testing data ini akan selalu di truncate dan di isi lagi dengan data testing untuk di testing
3. user data, ini adalah data real dari user ketika data sudah masuk production.
   

Oleh karena itu framework apapun baik itu symfony, ruby on rails, java ... khan pada dasarnya adalah best practise pengalaman para programmer2 yang membuat framework itu. Dan mereka selalu menyediakan 3 environment database :

1. production
2. test
3. development