1. Latar Belakang Masalah
Kebutuhan akan sistem informasi belakangan ini meningkat pesat. Hal itu dikarenakan setiap perusahaan ingin memiliki sebuah sistem yang mampu mengelola seluruh data yang dimilikinya dengan tepat. Dengan adanya sistem informasi, perusahaan dapat mengolah data yang dimilikinya dengan lebih efektif dan efisien. Sehingga para pengembang sistem informasi mau tidak mau harus terus melahirkan metode-metode yang mampu menghadapi keinginan pasar yang terus berkembang sesuai dengan tuntutan jaman.
Jika berbicara mengenai sistem informasi, kita akan dihadapkan pada masalah basis data. Karena dalam basis data inilah seluruh data yang ingin diakses melalui sistem informasi diperoleh. Sehingga tak heran jika basis data memegang peranan yang sangat penting dalam pembangunan sebuah aplikasi berupa sistem informasi. Untuk itu, dibutuhkan sebuah strategi penanganan basis data yang tepat agar dihasilkan sebuah sistem informasi yang baik.
Penanganan basis data yang tepat, selain harus dapat menyimpan informasi yang dibutuhkan juga harus dapat terelasi dengan baik, atau disebut juga dengan basis data relasional. Basis data relasional adalah kumpulan data yang berelasi antara satu dengan yang lain. Dan untuk dapat mengelola basis data relasional, diperlukan tools yang disebut RDBMS atau Relational Database Management System.
Saat ini tengah dikembangkan sebuah teknik mapping yang diperuntukkan bagi RDBMS. Teknik ini dikenal dengan sebutan ORM yang merupakan singkatan dari Object Relational Mapping. ORM adalah sebuah teknik yang digunakan untuk memetakan RDBMS ke dalam objek-objek. Dengan kata lain, ORM memodelkan data pada RDBMS ini dalam bentuk objek-objek, sehingga memudahkan dalam melakukan manipulasi atau operasi di basis data.
Ada beberapa implementasi ORM yang muncul belakangan ini. Doctrine dan Propel merupakan dua dari beberapa jenis ORM yang baru dikembangkan. Doctrine dan Propel merupakan ORM yang digunakan untuk memetakan basis data relasional menjadi objek-objek pada sistem informasi yang dibangun dengan menggunakan PHP versi 5.0 keatas.
Doctrine adalah sebuah ORM untuk PHP 5 yang terletak di atas DBAL (Database Abstraction Layer). Salah satu fitur yang menjadi andalannya adalah kemampuan dalam menuliskan query basis data dalam bentuk OO (Object Oriented) SQL-dialect atau yang dikenal dengan DQL yang terinspirasi oleh Hibernates HQL.
Propel adalah sebuah ORM yang digunakan untuk PHP versi 5. Propel memberikan kemudahan dalam mengakses basis data menggunakan objek-objek, menyediakan API sederhana untuk menambah dan mengolah data. Beberapa kelebihan yang dimiliki oleh Propel, antara lain:
• Tidak perlu khawatir terhadap koneksi-koneksi basis data atau penulisan SQL
• RDBMS di definisikan ke dalam sebuah format XML yang sederhana (atau Propel bisa juga membangunnya dari basis data yang sudah ada) dan Propel akan membuat file-file inisialisasinya untuk basis data yang akan dibangun serta akan meng-generate kelas-kelas statis dan objek-objek ke dalam sebuah OO interface ke dalam basis data yang dibuat.
• Propel membangun kelas-kelas berdasarkan struktur dari basis data agar performansinya meningkat.
Dengan beragamnya jenis ORM yang bisa digunakan, perlu di analisa tentang performansi dari jenis-jenis ORM ini. Sehingga nantinya jenis ORM yang digunakan bisa optimal sesuai dengan kebutuhan yang diharapkan.
2. Tujuan
Setelah melihat dari latar belakang di atas, penulis bermaksud mengerjakan tugas akhir ini dengan tujuan sebagai berikut :
1. Membangun sebuah simulasi pengolahan basis data menggunakan ORM Doctrine dan Propel.
2. Membandingkan performansi mapping dari dua ORM untuk PHP yaitu Doctrine dan Propel dengan tiga skenario pengujian, yaitu :
• Pengujian performansi saat operasi CRUD dieksekusi dengan parameter analisis throughput system.
• Pengujian maintainability dengan analisis perubahan LoC.
• Pengujian fleksibilitas basis data dengan menggunakan dua basis data yang berbeda.
3. Rumusan Masalah dan Batasan Masalah
Perkembangan pesat yang ditunjukkan oleh para developer dalam mengembangkan ORM belakangan ini sangat signifikan. Jika dalam beberapa tahun terakhir jumlah ORM yang dikembangkan jumlahnya terbatas, kini banyak muncul jenis-jenis baru dari ORM. Hal ini dikarenakan para developer mulai melihat bahwa sebagian besar perusahaan kini mulai menggunakan ORM untuk mengolah basis data mereka. Baik itu di lingkungan Java, PHP, maupun .NET. Oleh karena itu diperlukan suatu analisis mengenai performansi dari ORM tersebut, agar didapatkan suatu strategi mapping persistensi data yang tepat.
Dengan melakukan analisa terhadap ORM Doctrine dan Propel, diharapkan nantinya dapat menjadi parameter untuk menentukan ORM mana yang tepat digunakan untuk melakukan pengolahan basis data dengan mempertimbangkan performansi dari keduanya. Sehingga muncul rumusan masalah sebagai berikut :
1. Manakah diantara kedua ORM yang dibandingkan yaitu antara Doctrine dan Propel, yang lebih efektif digunakan untuk melakukan pengolahan basis data?
2. Bagaimana fleksibilitas ORM Doctrine dan Propel terhadap RDBMS yang digunakan?
Adapun batasan masalah pada Tugas Akhir ini, yaitu :
1. RDBMS yang digunakan adalah MySQL versi 5.0.51b
2. Bahasa pemrograman yang digunakan adalah PHP versi 5.2.9
3. ORM yang akan dibandingkan adalah Doctrine versi 1.0.3 dan Propel 1.3.0
4. Simulasi pengolahan basis data yang dibangun adalah contoh dari penerapan ORM Doctrine dan Propel.
4. Metode Penelitian
Metode yang digunakan dalam penyelesaian tugas akhir ini adalah menggunakan metode studi literatur dan analisis dengan langkah-langkah sebagai berikut :
1. Studi Literatur :
a. Pencarian referensi
Mencari referensi yang berhubungan dengan PHP, MySQL, ORM, Propel, dan Doctrine.
b. Pendalaman materi
Mempelajari dan memahami metode dan software yang digunakan serta materi yang berhubungan dengan tugas akhir.
2. Merancang simulasi pengolahan basis data yang ingin di bangun sesuai dengan kebutuhan.
3. Membangun simulasi pengolahan basis data berdasarkan rancangan yang telah dibuat menggunakan software yang dianalisa.
4. Melakukan pengujian dan analisa terhadap simulasi pengolahan basis data yang telah dibangun.
5. Pengambilan kesimpulan dan penyusunan laporan tugas akhir.
Monday, 26 January 2009
Monday, 8 September 2008
CMS or Framework
Menggunakan CMS atau Framework?
Tags: cakephp, cms, codeigniter, drupal, framework, opensource, rubyonrails, Website
Saya termasuk orang yang mengembangkan website tanpa pernah membuatnya dari nol. Maksudnya, saya tidak membuat komponen dari website itu secara manual satu demi satu. Mulai dari arsitektur website, komponen modul, file uploader, user access, image manager, dll. Biasanya semua dilakukan dengan menggunakan CMS yang OpenSource, seperti Wordpress dan Drupal (jaman dulu juga termasuk PHPNuke). Biasanya memang saya melakukan modifikasi disana - sini agar website ini bisa bekerja sesuai keinginan. Umumnya akhirnya website tersebut akhirnya bisa berjalan sesuai harapan.
Tetapi kemudian datang masalah seperti berikut ini :
1. Website tersebut membutuhkan galery foto dengan fasilitas slideshow.
2. Website tersebut membutuhkan katalog produk.
3. Website tersebut ingin mengimplementasikan fasilitas social network.
4. Website itu ingin menyediakan fasilitas bagi membernya untuk bisa mengupload file MP3. Dan tiap member nantinya bisa mengatur level akses terhadap file MP3 yang dia upload.
5. Website tersebut ingin mempunyai form yang terintegrasi untuk arsip wawancara.
6. dll
Jika saya menggunakan CMS seperti Drupal. Mungkin hal ini masih bisa ditangani dengan ketersediaan modulnya yang sangat banyak. Atau jika memang modulnya belum tersedia, kita bisa membuat sendiri. Selain itu jika kurang puas, kita masih bisa melakukan oprek lebih dalam dengan menggunakan API yang disediakan Drupal. Dengan tujuan agar website ini sesuai dengan apa yang kita inginkan.
Tetapi, hal ini bisa jadi merupakan masalah baru. Tentunya kadangkala hal ini bisa menjadi solusi untuk satu masalah tetapi bukan tidak jarang malah menimbulkan masalah baru. Beberapa skenario yang sering terjadi :
1. Modul untuk CMS tersedia. Tetapi ada bagian yang tidak sesuai, bahkan mungkin ada bagian yang akhirnya malah terasa mengganggu. Misal modul e-commerce dari Drupal menyediakan begitu banyak fasilitas yang pada kenyataannya tidak saya butuhkan. Sedangkan untuk beberapa bagian justru masih belum sesuai harapan. Dan untuk bisa merubah modul ini, kita harus memahami hampir kesuluruhan struktur modul ini. Ditambah pengetahuan tentang API dari Drupal.
2. Terlalu banyak pilihan modul. Misal modul untuk upload gambar di Drupal. Secara default tidak ada. Kita masih bisa menginstal modul tambahan, sehingga nantinya upload gambar di Drupal akan semudah di Wordpress. Tetapi ketika sampai di tahap theming, saya menyadari bahwa field untuk gambar hasil upload modul tersebut tidak bisa diakse langsung. Berbeda dengan image yang diupload menggunakan bantuan module Image Field (CCK).
3. Dengan API yang disediakan, kadangkala kita masih membutuhkan pengetahuan tentang API lain. Dan pada akhirnya mau tidak mau saya harus mempelajari banyak API, hanya untuk mengetahui bagian mana dari API ini yang tepat untuk solusi masalah saya.
4. Salah satu hal yang paling sulit adalah merubah alur kerja dari website ini. Misal jika user ingin register, tidaklah langsung ditampilkan ke halaman register, tetapi harus melalui satu halaman polling terlebih dahulu. Untuk bisa mengimplementasikan ini, secara tidak langsung kita harus tahu alur kerja (workflow) dari CMS yang kita gunakan.
5. Butuh field yang custom untuk tiap post (tidak hanya field TITLE dan POST saja). Secara default Wordpress menyediakan fasilitas Custom Fields, tetapi penggunaannya masih belum senyaman CCK di Drupal. Untuk itu harus dibuat modul sendiri.
6. dll
Jika memang akhirnya saya ingin menjadi ahli dari CMS tersebut, saya rasa tidak masalah untuk mengikuti solusi yang saya berikan di atas. Tetapi jika saya hanya ingin menggunakan CMS ini sebagai bantuan, sepertinya effort nya terlalu besar.
Bahkan tidak jarang saya merasa, ketika mempelajari semua API, hook, templating, konvensi, dll dari suatu CMS, effortnya mungkin sama besarnya dengan jika saya membangun website tersebut dari nol.
Jadi apakah akhirnya membuat CMS dari nol?
Tidak. Bagi saya tetap tidak. Karena ada beberapa kemudahan di CMS yang tidak saya dapatkan jika saya harus membangun dari nol. Saya harus membangun kerangka / arsitektur dari website tersebut. Dan cukup banyak pula waktu yang tersita untuk membangunnya.
Jadi apa solusinya?
Framework. Bagi saya solusi di tengah - tengahnya adalah framework. Framework menjadi solusi yang tepat jika saya ingin mengembangkan website yang berbasis konten, tetapi dengan beberapa fasilitas yang tidak umum (seperti kasus di atas tadi). Dengan framework yang tepat, saya bisa membuat API saya sendiri, tetap mendapatkan fasilitas templating secara default, fasilitas layering untuk database, dan salah satu yang paling saya sukai adalah fasilitas URL Friendly secara default. Saya tidak tahu apakah semua framework menyediakan fasilitas tersebut, tetapi yang jelas Framework yang saya pakai (CodeIgniter) menggunakannya.
Pilihan framework yang cukup terkenal :
1. Prado - PHP (contoh : website Univertias Indonesia) : Kalau tidak salah ini seperti menjadi ASP.Net pada PHP
2. CodeIgniter - PHP(contoh : OkeZone.com), Jujur saja, saya tahu CodeIgniter dari situs OkeZone ini, dan sampai saat ini paling nyaman menggunakan ini, karena framework ini terdokumentasi dengan baik.
3. Ruby On Rails - Ruby (contoh : SharingFoto.com) : Situs ini diklaim sebagai web aplikasi pertama di Indonesia yang menggunakan Ruby On Rails.
4. CakePHP - PHP (contoh : OwnCafe.com) : Salah seorang yang sangat aktif dalam edukasi CakePHP di Indonesia adalah Sunu Wibirama (alumni Teknik Elektro UGM). Situs lokal cake-php bisa dilihat di idcake.web.id
5. Symfony (PHP), Django (Python), dll
Saya sendiri masih penasaran dan menantikan Mambo CMS versi 5.0 yang akan menggunakan CakePHP sebagai basisnya. Dengan kondisi seperti itu, maka level kustomisasi bisa dilakukan dari tingkat yang paling dasar (langsung menggunakan framework),di lapis tengah (modul), maupun lapis akhir (theming).
Jika ada yang tertarik dengan framework - framework di atas, jangan lupa pahami satu istilah ini : MVC (Model View Controller).
Tags: cakephp, cms, codeigniter, drupal, framework, opensource, rubyonrails, Website
Saya termasuk orang yang mengembangkan website tanpa pernah membuatnya dari nol. Maksudnya, saya tidak membuat komponen dari website itu secara manual satu demi satu. Mulai dari arsitektur website, komponen modul, file uploader, user access, image manager, dll. Biasanya semua dilakukan dengan menggunakan CMS yang OpenSource, seperti Wordpress dan Drupal (jaman dulu juga termasuk PHPNuke). Biasanya memang saya melakukan modifikasi disana - sini agar website ini bisa bekerja sesuai keinginan. Umumnya akhirnya website tersebut akhirnya bisa berjalan sesuai harapan.
Tetapi kemudian datang masalah seperti berikut ini :
1. Website tersebut membutuhkan galery foto dengan fasilitas slideshow.
2. Website tersebut membutuhkan katalog produk.
3. Website tersebut ingin mengimplementasikan fasilitas social network.
4. Website itu ingin menyediakan fasilitas bagi membernya untuk bisa mengupload file MP3. Dan tiap member nantinya bisa mengatur level akses terhadap file MP3 yang dia upload.
5. Website tersebut ingin mempunyai form yang terintegrasi untuk arsip wawancara.
6. dll
Jika saya menggunakan CMS seperti Drupal. Mungkin hal ini masih bisa ditangani dengan ketersediaan modulnya yang sangat banyak. Atau jika memang modulnya belum tersedia, kita bisa membuat sendiri. Selain itu jika kurang puas, kita masih bisa melakukan oprek lebih dalam dengan menggunakan API yang disediakan Drupal. Dengan tujuan agar website ini sesuai dengan apa yang kita inginkan.
Tetapi, hal ini bisa jadi merupakan masalah baru. Tentunya kadangkala hal ini bisa menjadi solusi untuk satu masalah tetapi bukan tidak jarang malah menimbulkan masalah baru. Beberapa skenario yang sering terjadi :
1. Modul untuk CMS tersedia. Tetapi ada bagian yang tidak sesuai, bahkan mungkin ada bagian yang akhirnya malah terasa mengganggu. Misal modul e-commerce dari Drupal menyediakan begitu banyak fasilitas yang pada kenyataannya tidak saya butuhkan. Sedangkan untuk beberapa bagian justru masih belum sesuai harapan. Dan untuk bisa merubah modul ini, kita harus memahami hampir kesuluruhan struktur modul ini. Ditambah pengetahuan tentang API dari Drupal.
2. Terlalu banyak pilihan modul. Misal modul untuk upload gambar di Drupal. Secara default tidak ada. Kita masih bisa menginstal modul tambahan, sehingga nantinya upload gambar di Drupal akan semudah di Wordpress. Tetapi ketika sampai di tahap theming, saya menyadari bahwa field untuk gambar hasil upload modul tersebut tidak bisa diakse langsung. Berbeda dengan image yang diupload menggunakan bantuan module Image Field (CCK).
3. Dengan API yang disediakan, kadangkala kita masih membutuhkan pengetahuan tentang API lain. Dan pada akhirnya mau tidak mau saya harus mempelajari banyak API, hanya untuk mengetahui bagian mana dari API ini yang tepat untuk solusi masalah saya.
4. Salah satu hal yang paling sulit adalah merubah alur kerja dari website ini. Misal jika user ingin register, tidaklah langsung ditampilkan ke halaman register, tetapi harus melalui satu halaman polling terlebih dahulu. Untuk bisa mengimplementasikan ini, secara tidak langsung kita harus tahu alur kerja (workflow) dari CMS yang kita gunakan.
5. Butuh field yang custom untuk tiap post (tidak hanya field TITLE dan POST saja). Secara default Wordpress menyediakan fasilitas Custom Fields, tetapi penggunaannya masih belum senyaman CCK di Drupal. Untuk itu harus dibuat modul sendiri.
6. dll
Jika memang akhirnya saya ingin menjadi ahli dari CMS tersebut, saya rasa tidak masalah untuk mengikuti solusi yang saya berikan di atas. Tetapi jika saya hanya ingin menggunakan CMS ini sebagai bantuan, sepertinya effort nya terlalu besar.
Bahkan tidak jarang saya merasa, ketika mempelajari semua API, hook, templating, konvensi, dll dari suatu CMS, effortnya mungkin sama besarnya dengan jika saya membangun website tersebut dari nol.
Jadi apakah akhirnya membuat CMS dari nol?
Tidak. Bagi saya tetap tidak. Karena ada beberapa kemudahan di CMS yang tidak saya dapatkan jika saya harus membangun dari nol. Saya harus membangun kerangka / arsitektur dari website tersebut. Dan cukup banyak pula waktu yang tersita untuk membangunnya.
Jadi apa solusinya?
Framework. Bagi saya solusi di tengah - tengahnya adalah framework. Framework menjadi solusi yang tepat jika saya ingin mengembangkan website yang berbasis konten, tetapi dengan beberapa fasilitas yang tidak umum (seperti kasus di atas tadi). Dengan framework yang tepat, saya bisa membuat API saya sendiri, tetap mendapatkan fasilitas templating secara default, fasilitas layering untuk database, dan salah satu yang paling saya sukai adalah fasilitas URL Friendly secara default. Saya tidak tahu apakah semua framework menyediakan fasilitas tersebut, tetapi yang jelas Framework yang saya pakai (CodeIgniter) menggunakannya.
Pilihan framework yang cukup terkenal :
1. Prado - PHP (contoh : website Univertias Indonesia) : Kalau tidak salah ini seperti menjadi ASP.Net pada PHP
2. CodeIgniter - PHP(contoh : OkeZone.com), Jujur saja, saya tahu CodeIgniter dari situs OkeZone ini, dan sampai saat ini paling nyaman menggunakan ini, karena framework ini terdokumentasi dengan baik.
3. Ruby On Rails - Ruby (contoh : SharingFoto.com) : Situs ini diklaim sebagai web aplikasi pertama di Indonesia yang menggunakan Ruby On Rails.
4. CakePHP - PHP (contoh : OwnCafe.com) : Salah seorang yang sangat aktif dalam edukasi CakePHP di Indonesia adalah Sunu Wibirama (alumni Teknik Elektro UGM). Situs lokal cake-php bisa dilihat di idcake.web.id
5. Symfony (PHP), Django (Python), dll
Saya sendiri masih penasaran dan menantikan Mambo CMS versi 5.0 yang akan menggunakan CakePHP sebagai basisnya. Dengan kondisi seperti itu, maka level kustomisasi bisa dilakukan dari tingkat yang paling dasar (langsung menggunakan framework),di lapis tengah (modul), maupun lapis akhir (theming).
Jika ada yang tertarik dengan framework - framework di atas, jangan lupa pahami satu istilah ini : MVC (Model View Controller).
Subscribe to:
Posts (Atom)
