Membongkar Teknologi Framework MVC Bagian Empat

Membongkar Teknologi Framework MVC Bagian Empat

EKO HERI SUSANTO·14 DESEMBER 2015

Secara umum inti dari catatan kali ini adalah bagaimana menerapkan registry dan singleton pattern untuk menangani dependent full (ketergantungan penuh) antara class controller dengan class model, class library ataupun helper. Framework CodeIgniter, Obullo dan beberapa framework yang lain memanfaatkan registry dan singleton pattern ini sebagai inti (core) sistem-nya. Memang tidak semua framework MVC menerapkan registry dan singleton pattern. Framework Laravel, Symfony, Pimple, Zend menerapkan dependency injection pattern sebagai core systemnya. Untuk penerapan dependency injection pattern, Insya Allah akan saya bahas pada artikel/catatan versi berikutnya.

Sedikit saya ulas pada catatan saya sebelumnya bahwa dependent full (ketergantungan penuh) pada relasi antar class controller, model, database driver ataupun library harus diminimalisir agar mempermudah dalam proses pembuatan website yang menganut konsep Software Development Live Cicle (SDLC). Sedikit saya ulas kembali catatan saya pada bagian pertama dan kedua seperti yang terlihat pada gambar 1 berikut ini.

Gambar 1 : Review catatan bagian pertama dan kedua

Terlihat pada gambar 1 diatas, terdapat relasi yang bersifat dependent full antara controller dengan model dan model dengan database driver. Untuk mengatasi problem dependent antara model dengan database driver, sudah saya bahas penerapan dependency injection pattern seperti yang sudah saya tulis pada catatan bagian tiga. Jika anda belum membaca tulisan membongkar teknologi MVC bagian tiga, silahkan kunjungi link berikut ini https://www.facebook.com/notes/eko-heri-susanto/membongkar-teknologi-framework-mvc-bagian-tiga/107401534928

Jika diamati pada class controller, ternyata class controller juga masih mengandung dependent full (ketergantungan penuh) dengan class model. Gambar 2 berikut ini menggambarkan ilustrasi bagaimana ketergantungan penuh antara class controller dengan class model tersebut terbentuk, serta bagaimana akibat yang ditimbulkan jika class controller terhubung secara penuh dengan class model.

Gambar 2 : dependent full pada class controller dengan class model

Pada gambar 2 tampak beberapa hal yang tidak fleksibel. Misalnya untuk mengakses sebuah model, kita harus menyediakan satu buah variable. Walaupun program diatas jika dijalankan tidak ada kendala, namun jika dilihat dari segi arsitektur pembangunan (development) software, hal ini terlihat tidak efisien. Bisa dibayangkan jika dalam sebuah controller harus memanggil lebih dari 1 (satu) model atau memanggil beberapa library, tentunya kita harus menyediakan variable sebanyak model atau library yang akan kita panggil. Tentu ini tidak praktis dan akan menyulitkan kita jika kelak dikemudian hari aplikasi tersebut akan kita kembangkan.

Pertanyaannya adalah bagaimana membuat relasi yang baik antara class controller dengan class model? atau mungkin class controller dengan class library? Untuk menjawab pertanyaan ini, saya akan mencoba menerapkan registry pattern dan singleton pattern pada aplikasi framework kita. Untuk lebih jelasnya, ilustrasi gambar 3 dibawah ini akan menjelaskan bagaimana kita menerapkan registry dan singleton pattern pada MVC kita.

Gambar 3 : Konsep Penerapan Registry Pattern

Desain class diagram dari konsep registry pattern tersebut, bisa anda lihat seperti gambar 4 berikut ini.

Gambar 4 : Desain class diagram penerapan registry pattern

Dari gambar 3 dan gambar 4, terlihat bahwa class controller tidak terhubung langsung dengan class model maupun class library. Class controller terhubung dengan class loader, dimana class loader itu sendiri yang nantinya akan memanggil sekaligus mendaftar class model atau library yang akan digunakan. Dengan konsep semacam ini, maka loose coupling antara controller dengan model ataupun library dapat diwujudkan.

Jika anda bertanya class base itu apa? untuk apa? berarti anda mempunyai pertanyaan yang bagus. Bagaimana jawabannya? (kasih tau gak ya? :D ) . Begini ceritanya. Konsep besarnya registry pattern itu bisa diibaratkan seperti kita menyediakan sebuah tempat penampungan. Jadi jika ada object yang akan digunakan baik itu model ataupun library, maka object tadi kita tampung pada sebuah wadah penampungan itu tadi. Class base berfungsi untuk menampung semua object yang akan kita gunakan. Selanjutnya controller-lah yang akan mengambil object dari penampungan (class base) itu tadi. Bagaimana penampungan (class base) itu diisi? tentunya untuk mengisi penampungan itu, harus ada program lain yang bertugas mendaftarkan object yang akan digunakan. Pekerjaan loader inilah yang akan mendaftarkan object yang akan kita gunakan ke variable penampungan itu tadi. Untuk lebih jelasnya, ini saya sertakan gambar script class base, seperti yang terlihat pada gambar 5 berikut ini.

Gambar 5 : Script class base

Pada gambar 5 diatas, terdapat wadah (variable) $instance yang bertugas mirip seperti “superman”. dialah yang bertugas menampung semua object yang dibutuhkan oleh controller. Sedangkan fungsi dari function getInstance() adalah sebagai penghubung wadah (variable) $instance pada class base dengan class loader. Untuk lebih jelasnya, silahkan dilihat script loader seperti pada gambar 6 berikut ini.

Gambar 6 : Script Loader

Pada gambar 6, selain menerapkan registry pattern juga terdapat penerapan singleton pattern. Fungsi singleton pattern itu apa sih sebenarnya? Singleton pattern itu sebenarnya hanya berfungsi untuk memastikan bahwa tidak ada pendaftaran object yang sama lebih dari satu kali (redundance registered). Kenapa object yang didaftarkan tidak boleh redundance? jawabannya sederhana untuk menghemat penggunaan memory.

Nah setelah registry dan singleton pattern sudah kita terapkan, bagaimana dengan controller-nya itu sendiri? Gambar 7 berikut ini menjelaskan bentuk dari controller yang terhubung dengan loader dan base.

Gambar 7 : Class Controller

Disini saya sengaja membuat controller baru yaitu third.php. Dimana third.php ini merupakan extends (turunan) dari class base. Class base tentunya harus menjadi induk dari semua controller, kenapa? jawabannya karena terkait dengan variable $instance yang jadi variable “superman” itu tadi. Kan semua object yang akan digunakan ditampung di variable $istance alias variable superman itu to? Gara-gara kita menggunakan variable $instance yang sistem kerjanya sama seperti “superman” itulah, akhirnya teknik loose coupling bisa kita wujudkan. Selain itu pemanggilan object juga terlihat lebih fleksibel, tidak diharuskan lagi mendeklarasikan sebuah variable khusus seperti yang dilakukan pada catatan sebelumnya.

Untuk membandingkan efisiensi arsitektur framework ini dengan arsitektur pada catatan sebelumnya, silahkan dilihat pada gambar 8 berikut ini. Silahkan diamati bagaimana controller sebelum catatan ini dibuat (second.php) dengan setelah catatan ini dibuat (third.php).

Gambar 8 : Perbandingan controller second.php versus controller third.php

Bagaimana? terlihat lebih rapi dan lebih fleksibel kan? Jika pada second.php, ketika kita akan mengakses sebuah model, kita harus menyediakan variable lokal. Seperti pada gambar 8 diatas ada deklarasi variable private $model. Dimana variable $this->model ini nantinya digunakan untuk meng-instance-kan class mymodel ($this->model = new mymodel). Jika kita lihat pada class third.php, tidak diperlukan lagi deklarasi variable lokal. Dengan memanggil nama class-nya saja, yaitu dengan menuliskan perintah loader::model(‘mymodel’) otomatis kita sudah meng-instance-kan class mymodel.

Untuk mempercepat pemahaman, ini saya sertakan contoh source aplikasinya. Untuk susunan file dan foldernya, silahkan dilihat pada gambar 9 berikut ini.

Gambar 9 : Susunan file dan Folder

Sedangkan contoh script-nya, silahkan di-download pada link berikut ini.

index.php : http://pastebin.com/Us95ci9E

base.php : http://pastebin.com/vBkUYrve

loader.php : http://pastebin.com/G27Sw1ve

third.php : http://pastebin.com/MBnyApR6

four_view.php : http://pastebin.com/4BkhUgJ6

five_view.php : http://pastebin.com/QSnucZDS

OK. Sampai disini dulu catatan kali ini, masih ada bagian selanjutnya yaitu membahas penerapan design pattern yang lain serta pembuatan library atau helper. Semoga ada guna dan manfaatnya. Terimakasih.

Tweet