Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby

Model Data Lanjutan dengan Rails

by
Read Time:10 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Shylchemist (you can also view the original English article)

Model, View, Controller. Jika Anda pernah mencoba Ruby on Rails, kata-kata itu mungkin telah tertanam ke kepala Anda ribuan kali. Di sisi lain, jika ini baru bagi Anda, ada banyak sumber di Nettuts+ untuk pemula - tetapi ini bukan salah satunya.

Jika Anda sedah sejauh ini, maka aman untuk menganggap Anda setidaknya pengguna perantara Rails. Jika demikian, saya ucapkan selamat kepada Anda! Kurva belajar yang paling sulit ada di belakang Anda. Sekarang, Anda dapat mulai menguasai hal-hal yang sangat keren. Dalam posting ini, saya ingin fokus pada sepertiga favorit saya dari MVC - yang menurut saya Rails paling baik: Model.


Orientasi Objek

Sejauh ini, hal terbaik tentang ActiveRecord (menurut saya) adalah bagaimana baris dalam basis data berhubungan secara langsung dengan kelas-kelas dalam kode Anda. Tapi jangan salah berasumsi bahwa kelas Model Anda adalah baris basis data! Sebaliknya, Anda harus menyadari bahwa kelas Model hanyalah cara untuk berinteraksi dengan database. Bagian yang brilian adalah Rails membuat proses ini begitu tanpa gesekan sehingga Anda mungkin berpikir bahwa Anda memanipulasi informasi secara langsung. Jangan membuat kesalahan ini.

Kunci untuk penguasaan Model menggunakan mereka sebagai kelas "reguler", dengan metode instance, metode kelas, atribut dan sejenisnya. Anda harus memperlakukan kolom dalam basis data seperti bagian dari Model Anda, mengaksesnya dari luar, tetapi juga menggunakannya dari dalam dalam konstruksi lain seperti instance dan metode pribadi. Belajarlah mengintegrasikan keduanya untuk sistem yang benar-benar berorientasi objek.

Semua yang dilakukan database adalah memberikan informasi. Kaulah yang harus memberikan logika.

Pikirkan objek Model sama seperti objek lainnya; jika ada logika di bagian lain dari kode Anda yang terkait dengan objek ini, selalu lebih baik untuk mengintegrasikannya di dalam kelas. Semua yang dilakukan database adalah memberikan informasi. Kaulah yang harus memberikan logika.

Metode

Katakanlah Anda memiliki Model yang sesuai dengan pos di blog. Anda memutuskan untuk menulis semua posting blog Anda dengan Markdown dan menyimpan hanya versi Markdown dalam database. Sekarang, Anda harus mem-parsing konten ini ke dalam HTML kapan pun Anda ingin menampilkannya.

File tampilan dasar ini akan menjalankan konten posting melalui metode setiap kali ditampilkan. Baik. Bagaimana kita bisa membuatnya lebih baik?

Saya telah mengonsolidasikan pemformatan konten menjadi metode instan. Meskipun ini belum memiliki efek yang terlihat, bayangkan jika nanti Anda memutuskan untuk menambahkan lebih banyak logika ke format, misalnya memeriksa untuk melihat apakah konten sudah dalam bentuk HTML. Cara ini akan membuat jauh lebih mudah untuk mengadaptasi kode nanti.

Ini juga memiliki manfaat tambahan untuk membuat kode Anda lebih teratur dan lebih mudah dibaca. Jika saya melihat proyek Anda, tempat pertama saya akan mencari metode seperti ini adalah di kelas Post Anda. Jenis organisasi ini secara langsung meniru jenis yang sudah dibangun ke dalam Rails: metode kecil dan ringan yang melekat pada kelas.

Metode Kelas

Metode kelas memungkinkan Anda menggabungkan metode yang terkait dengan fungsionalitas tertentu ke lokasi yang konsisten. Ini benar-benar bukan ide gila. Faktanya, sebagai pengembang Ruby perantara, itu adalah salah satu yang harus Anda sangat nyaman. Banyak yang tidak menyadari bahwa Anda juga dapat membangun metode kelas dalam suatu Model, tetapi Model adalah kelas seperti yang lainnya, mengapa kita tidak!?

Alih-alih menempatkan metode helper dalam file helper yang terpisah, tambahkan saja ke Model.

Contoh sempurna dari hal ini adalah metode helper, atau kode helper yang dikelompokkan berdasarkan tujuannya. Alih-alih menempatkan mereka dalam file/modul helper yang terpisah (yang seharusnya hanya digunakan untuk controller dan view helpers), tambahkan saja ke Model. Misalnya, jika Anda menginginkan metode yang akan memvalidasi keaslian username dan password yang diberikan, Anda dapat menerapkan metode User.authenticate(). Sekarang, jika nanti Anda ingin mengubah fungsi untuk otentikasi, akan mudah ditemukan di antara kode terkait Pengguna lainnya.

Yang terakhir adalah poin penting. Salah satu mantra Rails adalah "Convention over Configuration." Jika semua proyek menempel pada file dan struktur kode yang sama, mudah bagi developer lain untuk masuk dan mulai membuat perubahan pada proyek. Salah satu konvensi ini adalah pengelompokan metode pembantu terkait model sebagai metode kelas.

Metode pembantu yang hanya digunakan secara internal dalam Model juga dapat ada sebagai metode kelas. Dalam hal ini mereka akan menjadi metode pribadi atau dilindungi, tetapi ide dasarnya adalah sama. Jika metode ini membutuhkan informasi khusus untuk sebuah instance, itu adalah metode instance pribadi. Jika tidak, ini adalah metode kelas. Sesederhana itu, sungguh.

Virtual Atribut

Model bukanlah catatan dalam basis data. Mereka dibuat bukan ketika data ditulis ke database, tetapi ketika Anda, programmer, menginisialisasi mereka.

Untuk memahami Model dengan benar, Anda harus memahami gaya hidup objek mereka. Seperti yang saya katakan sebelumnya, Model bukanlah catatan dalam database. Mereka dibuat bukan ketika data ditulis ke database, tetapi ketika Anda, programmer, menginisialisasi mereka. Karena Model hanya merupakan interface ke data mentah basis data, Anda dapat membuat objek baru dari kelas agar sesuai dengan data yang ada.

Demikian juga, mereka dapat dihapus dengan memanggil metode penghancuran mereka. Ini menghapus baris dari database, dan juga menghapus objek Model.

Tetapi Anda dapat menghapus objek Model (bukan baris basis data!) Dengan mengatur variabel menjadi nil, atau membiarkannya keluar dari ruang lingkup.

Setelah Anda memahami hal ini, sepele untuk menyadari bahwa Model dapat memiliki atribut yang tidak sesuai dengan kolom basis data. Pikirkan tentang Model Pengguna. Pengguna ini memiliki nama pengguna dan kata sandi, tetapi karena Anda adalah programmer yang sadar akan keamanan, Anda hanya ingin menyimpan password yang di-hash dalam database, bukan password teks biasa.

Untuk mencapai hal ini, Anda dapat menerapkan "atribut virtual," atau variabel instan yang bukan kolom dalam basis data. Untuk mempermudah, pengguna tidak perlu melakukan konfirmasi password apa pun.

Ini adalah konstruksi Ruby murni dan sederhana yang menambahkan metode pengambil dan penyetel ke objek. Sekarang Anda dapat mengenkripsi kata sandi sebelum menyimpannya ke basis data, sehingga password teks biasa hanya disimpan dalam memori, bukan ditulis ke file apa pun.

Meskipun ini jauh dari implementasi yang sempurna (saya akan menunjukkan kepada Anda bagaimana memperbaikinya nanti di pos) itu menunjukkan kekuatan Atribut Virtual. Anda sekarang dapat melanjutkan untuk menerapkan metode encrypt_password apa pun yang Anda suka, mungkin memasukkan password yang tersimpan dalam memori bersama dengan beberapa jenis garam berdasarkan tanggal saat ini atau sesuatu seperti itu. Dalam hal ini, penting untuk memanggil metode itu sebelum menyimpan pengguna, sehingga password hash dihasilkan


Scopes

Pertimbangkan ini:

Benda ini berisi semua informasi yang diperlukan untuk mendapatkan data dari database. Objek menanggapi metode di atas, sehingga Anda dapat secara bertahap membangun database pertanyaan oleh chaining metode.

Cukup mudah. Kita baru saja membangun pertanyaan basis data dengan menggabungkan metode bersama. Namun, pernahkah Anda berpikir: dari mana metode itu berasal? Sebenarnya sangat sederhana. Metode tertentu seperti .where(), .order() dan .select() semuanya digunakan untuk menghasilkan pertanyaan. Mereka melakukan ini dengan semua objek yang kembali dari kelas ActiveRecord::Relation. Objek-objek ini berisi semua informasi yang diperlukan untuk mendapatkan data dari database. Objek merespons metode di atas, sehingga Anda dapat secara bertahap membangun pertanyaan basis data dengan merantai metode.

Metode-metode ini disebut lingkup. Seperti yang dapat Anda bayangkan, mereka adalah tool yang sangat kuat, dibuat dua kali lipat oleh fakta bahwa Anda dapat membuat lingkup Anda sendiri!

Bayangkan kembali Model Pos kita. Untuk menampilkan posting, Anda sering ingin agar mereka muncul dalam urutan pembuatannya. Namun, menjadi tidak praktis untuk memakukan .order("Created_at ASC") untuk setiap permintaan yang Anda tulis. Anda bisa menerapkannya dalam metode kelas Post, seperti ini:

Sekilas, ini sepertinya solusi yang bagus. Kita telah menggabungkan kode yang relevan ke objek, seperti pengembang berorientasi objek yang baik, jadi apa masalahnya. Masalahnya adalah jika Anda mencoba membangun pertanyaan seperti sebelumnya:

Karena hanya Post yang memiliki metode ini, Anda akan melihat kesalahan seperti ini:

Jadi apa yang harus dilakukan seorang pria. Sederhana.

Besar! Sekarang contoh dari atas berfungsi dengan baik, ditambah lagi kita masih memiliki kode di tempat yang tepat, dalam Model Posting kita.

Scopes sangat fleksibel. Jika Anda mau, Anda bisa menulis contoh di atas seperti ini:

Argumen kedua ke metode scope bisa berupa hash (seperti contoh pertama), objek ActiveRecord::Relation (seperti contoh kedua), atau bahkan lambda (fungsi anonim) seperti ini:

Dengan teknik ini, Anda bahkan bisa meneruskan argumen ke .chronological. Mungkin boolean untuk memesan naik atau turun?

Dan panggil metode seperti ini:

Anda dapat melakukan lebih dari sekedar memesan.

Hal terakhir yang ingin saya perlihatkan kepada Anda tentang cakupan adalah bahwa Anda dapat menyediakan apa yang disebut sebagai default_scope. Ini adalah scope yang akan diterapkan ke setiap permintaan berdasarkan Model ini. Jika Anda hanya ingin menampilkannya dalam urutan kronologis, Anda dapat melakukannya:

Bukankah ini menyenangkan?


Callback

Jika Anda ingat contoh enkripsi password saya dari atas, Anda akan ingat bahwa saya menyebutkan bahwa cara kita memanggil metode encrypt_password dapat ditingkatkan. Ini cuplikan asli untuk referensi:

Seperti yang Anda lihat, jika kami mengenkripsi sandi dengan cara ini, kita harus memanggil metode enkripsi yang setiap kali kita menginisialisasi pengguna baru. Jika kita lupa untuk menyebutnya, pengguna tidak akan memiliki password terpotong. Jauh dari solusi yang ideal.

Untungnya, dalam mode Rails yang khas, ada cara sederhana untuk memperbaikinya.

Kita dapat menggunakan apa yang disebut callback, atau sepotong kode yang dipanggil saat fase tertentu dari siklus hidup objek tercapai. Contohnya:

  • Sebelum menyimpan
  • Setelah menyimpan
  • Sebelum validasi
  • Setelah validasi

Benar-benar sesederhana itu. Setiap kali objek pengguna akan diselamatkan, sebuah metode dipanggil. Bahkan, Anda bahkan tidak perlu menggunakan metode!

Alih-alih meneruskan simbol ke panggilan before_save, Anda bisa memberikannya blok kode. Ini sangat ideal untuk situasi di mana kode yang Anda panggil hanya satu atau dua baris, atau jika hanya pernah digunakan sebelum menyimpan catatan.

Daftar lengkap metode callback tersedia dalam dokumentasi API. Mereka termasuk yang seperti before_validation, after_validation, after_save, dan lainnya. Ada banyak dari mereka, tetapi semuanya bekerja persis seperti yang Anda harapkan setelah melihat before_save beraksi.


Informasi di atas berbicara sendiri, jadi saya akan membuat singkat ini. Semoga Anda telah mempelajari sesuatu, bahkan mungkin beberapa hal. Jika Anda sudah mengetahui hal ini, kiat apa yang akan Anda berikan kepada orang lain tentang Model Rails? Posting mereka dalam komentar dan terus belajar!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.