Flash Sale! Up to 40% off on unlimited courses, tutorials and creative asset downloads Up to 40% off on unlimited assets SAVE NOW
Advertisement
  1. Code
  2. Ruby on Rails
Code

AntiPatterns Basics: Rails Controllers

by
Length:LongLanguages:

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

Jika Anda pernah hidup dengan diet "fat models, skinny controllers", Anda pasti menuju ke arah yang benar. Namun, menjaga pengendali tetap kurus tidak semudah kedengarannya. Dalam artikel ini Anda akan belajar beberapa pendekatan ramah-pemula untuk kehilangan beberapa lemak kontroler.

Topik

  • Fat Controllers
  • Non-RESTful Controllers
  • Rat’s Nest Resources

FAT Controllers

Baik, “fat models, skinny controllers”, betul? Jika Anda belum membaca artikel AntiPattern sebelumnya, saya harus menyebutkan bahwa membidik model dan pengontrol yang tetap kurus adalah pedoman yang lebih baik—apa pun yang terjadi. Semua kelebihan lemak itu tidak baik untuk proyek Anda—'segalanya kurus' lebih masuk akal. (Mungkin saya harus menjelaskan bahwa saya tidak terkait dengan industri fashion dengan cara apa pun dan tidak ingin mengulangi kesan bahwa Anda tidak dapat dianggap cantik tanpa memasang jenis tubuh imajiner tertentu.)

Seperti halnya model, Anda menginginkan pengontrol yang memiliki tanggung jawab tunggal. Pengendali harus benar-benar bodoh, mengatur lalu lintas dan tidak banyak lagi. Juga, jika mungkin, kami ingin membuat templat kami sebodoh mungkin-presenter bisa berguna dalam hal itu.

Lebih lanjut penting bahwa Anda tidak menyimpang banyak dari tindakan pengontrol tenang. Tentu saja, kadang-kadang masuk akal untuk memiliki metode tambahan di sana, tetapi sebagian besar waktu, Anda harus merasa sedikit tidak nyaman memilikinya. Pengendali cenderung menjadi gemuk ketika mereka mengumpulkan logika bisnis yang sebenarnya termasuk dalam model atau ketika pengembang yang tidak berpengalaman tidak menggunakan konvensi Rails.

Anda tidak akan menjadi yang pertama mencoba untuk menemukan kembali roda, dan Anda tentu tidak akan menjadi yang terakhir. Jangan merasa sedih tentang hal itu, karena mungkin sebagian besar dari kita sudah ada di sana, tetapi sebagai pengrajin, Anda benar-benar harus menginvestasikan waktu dan upaya untuk mengetahui konvensi, manfaat, dan keterbatasan kerangka kerja yang Anda gunakan—setidaknya untuk tujuan komersial di seseorang membayar keahlian Anda. Eksperimen selalu baik, tentu saja.

Karena pengendali bertanggung jawab atas aliran aplikasi Anda serta mengumpulkan informasi yang dibutuhkan pandangan Anda, mereka sudah memiliki tanggung jawab yang cukup penting. Mereka benar-benar tidak membutuhkan kompleksitas tambahan dari ranah model Anda. Pengontrol bekerja erat dengan pandangan Anda untuk menampilkan data yang disediakan oleh lapisan model. Hubungan mereka lebih erat daripada dengan model. Lapisan model berpotensi dikembangkan lebih mandiri dari yang lain. Hal yang baik tentang itu adalah bahwa lapisan pengontrol yang bersih seringkali memiliki efek positif pada seberapa rapi pandangan Anda.

Yang ingin saya sampaikan adalah bahwa pengontrol lemak sangat umum di tanah Rails—terutama di kalangan pemula dan pengembang yang tidak berpengalaman—dan dengan sedikit cinta dan perhatian, ini dapat dioptimalkan dengan mudah.

Langkah pertama sangat mudah. Tanyakan pada diri Anda kapan pengontrol tumbuh dalam ukuran jika kompleksitas berasal dari logika bisnis yang ditambahkan. Jika demikian, cari cara untuk memindahkannya ke lapisan model tempat Anda memiliki manfaat tambahan dengan memiliki rumah yang lebih baik untuk menguji kode kompleks.

Presenter

Untuk mengikuti rekomendasi di atas untuk memindahkan logika controller yang didapat ke model, presenter bisa menjadi teknik yang praktis. Mereka dapat mensimulasikan model sambil menggabungkan beberapa atribut terkait longgar bersama-sama, yang dapat berguna untuk menjaga pengendali tetap ramping dan seksi. Selain itu, mereka juga pandai menjaga logika nastiness dari pandangan Anda. Cukup bagus untuk membuat objek tambahan!

Penyaji dapat "meniru" model yang mewakili keadaan yang dibutuhkan pandangan Anda dan menggabungkan atribut yang perlu bergerak melalui pengontrol. Mereka bisa lebih kompleks, tapi kemudian saya merasa mereka melayang ke wilayah "Dekorator".

Terkadang controller bertugas membuat banyak model secara bersamaan dan kami ingin menghindarinya menangani beberapa variabel instan di sana. Mengapa ini penting? Karena itu membantu kita menjaga kesesuaian aplikasi kita. Presenter mengagregasi perilaku dan atribut, yang membuatnya mudah bagi pengendali kami untuk fokus pada pekerjaan kecil yang sederhana—dengan satu objek. Juga, memformat data dalam tampilan Anda atau fungsi kecil serupa lainnya adalah pekerjaan yang sering terjadi. Memiliki ini terkandung dalam presenter tidak hanya bagus untuk pandangan yang bersih tetapi juga karena memiliki tempat khusus yang membuat menguji perilaku ini secara langsung—lapisan model lebih mudah untuk diuji. Lebih banyak "bang for the buck" dan semua jazz itu.

Jika Anda menemukan Pola Presenter dan menemukan beberapa pendekatan atau cara berbeda untuk menggambarkannya, Anda tidak akan menjadi gila. Tampaknya ada sedikit kesepakatan yang jelas tentang apa itu presenter. Apa yang menjadi pengetahuan umum, adalah bahwa ia berada di antara lapisan MVC. Kita dapat menggunakannya untuk mengelola beberapa objek model yang perlu dibuat secara bersamaan. Saat menggabungkan objek-objek ini, ia meniru model ActiveRecord.

Skenario yang sering dikutip adalah semacam formulir yang memasukkan informasi untuk berbagai model berbeda, seperti akun pengguna baru yang juga memiliki bidang masukan untuk kartu kredit dan alamat atau sesuatu. Akan penyihir penuh dengan melangkah melalui beberapa bentuk dalam urutan tidak jauh berbeda. Karena bagian-bagian dari aplikasi Anda ini cenderung sangat penting, sudah pasti merupakan ide bagus untuk menjaga hal-hal tetap rapi sambil memiliki opsi terbaik yang tersedia untuk pengujian pada saat yang sama.

Pengalaman pengguna yang satu ini juga sangat penting. Dalam contoh di bawah ini, kami ingin membuat misi sederhana yang memiliki agent has_one dan satu quartermaster. Tidak ada ilmu roket, tetapi ini adalah contoh yang baik untuk melihat seberapa cepat hal-hal bisa lepas kendali. Pengontrol perlu menyulap beberapa objek yang dibutuhkan tampilan dalam bentuk bersarang untuk mengikat semuanya. Anda akan segera melihat bahwa semua ini dapat disembuhkan dengan "Formulir Objek" yang bagus yang menyajikan benda-benda yang dibutuhkan dan menjalin hal-hal bersama dalam satu kelas pusat.

app/models/mission.rb

Saya menyebutkan model di sini hanya demi kelengkapan jika Anda belum pernah menggunakan fields_for sebelumnya—sedikit disederhanakan tetapi berfungsi. Di bawah ini adalah inti masalahnya.

Variabel Instance Terlalu Banyak

app/controllers/missions_controller.rb

Secara keseluruhan, mudah untuk melihat bahwa ini menuju ke arah yang salah. Ini sudah menarik cukup banyak massa dan hanya terdiri dari metode new dan create. Tidak baik! Metode pribadi sudah menumpuk terlalu cepat juga. Memiliki agent_params dan quartermaster_params di MissionsController tidak terdengar terlalu apik untuk Anda, saya harap. Pemandangan yang langka, menurut Anda? Saya rasa tidak. "Tanggung Jawab Tunggal" pada controller benar-benar merupakan pedoman emas. Anda akan melihat alasannya hanya dalam satu menit.

Bahkan jika Anda menyipitkan mata, ini terlihat sangat jahat. Dan selama menyimpan dalam tindakan create, dengan validasi di tempat, jika kami tidak dapat menyimpan setiap objek karena kesalahan atau sesuatu, kami akan berakhir dengan objek yatim yang tidak ingin ditangani oleh siapa pun. Yikes!

Tentu, kita bisa memasukkan ini ke dalam blok transaction, yang berhasil menyelesaikan penghematan hanya jika semua objek beres, tetapi ini agak seperti berselancar melawan arus—juga, mengapa hal-hal tingkat model seperti ini di controller, benarkah? Ada cara yang lebih elegan untuk menangkap gelombang.

Mengikuti jalur ini, tampilan akan memiliki form_for untuk @mission dan tambahan fields_for @agent dan @quartermaster tentu saja.

Bentuk Berantakan Dengan Banyak Objek

app/views/missions/new.html.erb

Tentu, ini berhasil, tetapi saya tidak akan terlalu bersemangat untuk menemukan ini. fields_for memang praktis dan semuanya, tetapi menangani ini dengan OOP jauh lebih dope. Untuk kasus seperti itu, seorang presenter juga akan membantu kita memiliki pandangan yang lebih sederhana karena formulir hanya akan berurusan dengan satu objek. Bersarang formulir menjadi tidak perlu seperti itu. Ngomong-ngomong, saya meninggalkan pembungkus apa pun untuk menata formulir agar lebih mudah dicerna secara visual.

Bentuk Presenter Obyek

app/views/missions/new.html.erb

Seperti yang dapat Anda lihat dengan mudah, pandangan kami menjadi lebih sederhana—tidak ada sarang, dan jauh lebih mudah dari flat ini. Bagian yang Anda perlu sedikit berhati-hati adalah ini:

Anda perlu memberikan form_for dengan path melalui url sehingga bisa "memposting" params dari form ini ke controller yang tepat-di sini MissionsController. Tanpa argumen tambahan itu, Rails akan mencoba menemukan controller untuk objek presenter kami @mission_presenter melalui konvensi—dalam hal ini MissionFormPresentersController—dan meledak tanpa satu.

Secara umum, kita harus mencoba yang terbaik untuk menjaga tindakan pengontrol sebagian besar sesederhana berurusan dengan manipulasi sumber daya CRUD—itulah yang dilakukan pengontrol untuk mencari nafkah dan paling siap untuk melakukannya tanpa memperkeruh perbedaan MVC. Sebagai efek samping yang bagus, tingkat kerumitan pada pengontrol Anda akan turun juga.

app/controllers/missions_controller.rb

Pengontrolnya juga jauh lebih mudah di mata, bukan? Jauh lebih bersih dan cukup banyak tindakan pengontrol standar. Kami berhadapan dengan satu objek yang memiliki satu pekerjaan. Kami instantiate objek tunggal, presenter, dan memberi makan params seperti biasa.

Satu-satunya hal yang mengganggu saya adalah mengirimkan daftar panjang parameter kuat yang masuk daftar putih ini. Saya mengekstraknya menjadi metode yang disebut whitelisted, yang hanya mengembalikan array dengan daftar parameter lengkap. Kalau tidak, mission_params akan tampak seperti berikut—yang terasa terlalu jahat:

Oh, sepatah kata tentang argumen :mission_form_presenter untuk params.require. Meskipun kami menamai variabel instan kami untuk presenter @mission_presenter, ketika kita menggunakannya dengan form_for, Rails mengharapkan kunci dari hash params untuk formulir yang akan dinamai setelah objek dipakai - bukan setelah nama yang diberikan dalam controller. Saya telah melihat perjalanan pemula beberapa kali ini. Itu Rails memberi Anda kesalahan samar dalam kasus seperti itu tidak membantu. Jika Anda perlu sedikit penyegaran pada params, ini adalah tempat yang baik untuk menggali:

Dalam model Mission kami, kami sekarang tidak lagi perlu accepts_nested_attributes dan dapat menyingkirkan hal yang tampak tidak berbahaya dan menakutkan itu. Metode yang validates juga tidak relevan di sini karena kami menambahkan tanggung jawab ini ke objek formulir kami. Hal yang sama berlaku untuk validasi kami pada Agent dan Quartermaster, tentunya

app/models/mission.rb

Enkapsulasi logika validasi ini langsung pada objek baru kami membantu kami menjaga semuanya tetap bersih dan teratur. Dalam kasus di mana Anda juga bisa membuat objek-objek ini secara independen dari satu sama lain, validasi harus tetap di tempatnya saat ini, tentu saja. Duplikasi semacam ini juga dapat ditangani, misalnya dengan menggunakan validates_with dengan kelas terpisah untuk validasi yang diwarisi dari ActiveModel::Validator.

Sekarang kita memiliki pengontrol kurus dengan satu tanggung jawab dan bentuk datar untuk membuat beberapa objek secara paralel. Luar biasa! Bagaimana kita mencapai semua ini? Di bawah ini adalah presenter yang melakukan semua pekerjaan—tidak berarti kelas ini melakukan banyak pekerjaan. Kami ingin memiliki semacam model perantara tanpa database yang menyulap beberapa objek. Lihatlah objek ruby ​​tua polos ini (PORO)

app/presenters/mission_form_presenter.rb

Saya pikir itu adil untuk mengatakan bahwa itu tidak terlalu rumit. MissionFormPresenter adalah objek bentuk yang sekarang merangkum apa yang membuat controller kita menjadi gemuk. Sebagai bonus, tampilan kami menjadi datar dan sederhana. Apa yang terjadi di sini adalah bahwa kita dapat mengumpulkan semua informasi dari formulir kita dan kemudian kita membuat semua objek yang kita butuhkan secara berurutan.

Bagian paling penting terjadi dalam metode save baru kami. Pertama kita buat objek Mission baru. Setelah itu, kita bisa membuat dua objek yang terkait dengannya: Agent dan Quartermaster. Melalui asosiasi has_one dan belongs_to, kita dapat menggunakan metode create_x yang menyesuaikan dengan nama objek terkait

Sebagai contoh, jika kita menggunakan has_one :agent, kita mendapatkan metode create_agent. Mudah kan? (Sebenarnya kami juga mendapatkan metode build_agent.) Saya memutuskan untuk menggunakan versi dengan bang(!) Karena itu menimbulkan kesalahan ActiveRecord::RecordInvalid jika catatan tidak valid saat mencoba menyimpan. Dibungkus di dalam blok transaction, metode ledakan ini berhati-hati agar tidak ada objek yatim yang diselamatkan jika beberapa validasi masuk. Blok transaksi akan dibatalkan jika terjadi kesalahan selama penyimpanan.

Bagaimana cara kerjanya dengan atribut, Anda mungkin bertanya? Kami meminta Rails sedikit cinta melalui include ActiveModel::Model (API). Ini memungkinkan kita untuk menginisialisasi objek dengan hash atribut—yang persis apa yang kita lakukan di controller. Setelah itu, kita dapat menggunakan metode attr_accessor untuk mengekstraksi atribut kita untuk membuat instance objek yang benar-benar kita butuhkan.

ActiveModel::Model selanjutnya memungkinkan kita untuk berinteraksi dengan tampilan dan pengontrol. Di antara barang lainnya, Anda juga dapat menggunakan ini untuk validasi di kelas-kelas tersebut. Menempatkan validasi ini ke objek formulir khusus seperti itu adalah ide yang bagus untuk organisasi, dan itu juga membuat model Anda sedikit lebih rapi.

Saya memutuskan untuk mengekstrak daftar panjang parameter ke metode pribadi yang memberi makan objek yang dibuat di save. Dalam objek presenter seperti itu, saya tidak terlalu khawatir tentang memiliki beberapa metode pribadi yang lebih banyak. Mengapa tidak? Terasa lebih bersih!

Pengujian skenario semacam ini di mana beberapa model datang bersama-sama harus diperlakukan dengan sangat hati-hati—semakin sederhana objek yang dimaksud, semakin baik pengalaman pengujian. Tidak ada ilmu roket, sungguh. Presenter beroperasi untuk Anda dalam hal ini. Memiliki tes-tes ini yang berpotensi terikat pada pengontrol bukanlah cara terbaik untuk melakukan pendekatan ini. Ingat, tes unit cepat dan murah.

Sebuah kata peringatan. Jangan terlalu sering menggunakan presenter—itu seharusnya bukan pilihan pertama Anda. Biasanya, kebutuhan akan presenter tumbuh seiring waktu. Bagi saya pribadi, mereka paling baik digunakan ketika Anda memiliki data yang diwakili oleh beberapa model yang perlu disatukan dalam satu tampilan.

Tanpa presenter, Anda mungkin lebih sering tidak menyiapkan banyak variabel instan dalam pengontrol Anda untuk satu tampilan. Itu saja bisa membuat mereka sangat gemuk, sangat cepat. Satu hal yang harus Anda pertimbangkan dan timbang adalah bahwa sementara presenter menambahkan objek ke basis kode Anda, mereka juga dapat mengurangi jumlah objek yang perlu ditangani pengontrol—lebih sedikit kompleksitas dan tanggung jawab tunggal. Mungkin ini adalah teknik yang cukup canggih untuk menghilangkan lemak, tetapi ketika Anda ingin langsing, Anda perlu melakukan pekerjaan ini.

Non-RESTful Controllers

Tidak mencoba untuk mematuhi tindakan pengontrol standar kemungkinan besar merupakan ide yang buruk. Memiliki banyak metode pengontrol khusus adalah AntiPattern yang dapat Anda hindari dengan mudah. Metode seperti login_user, activ_admin, show_books, dan bisnis lucu lainnya yang berdiri untuk yang new, create, show, dan sebagainya, akan memberi Anda alasan untuk menjeda dan meragukan pendekatan Anda. Tidak mengikuti pendekatan RESTful dapat dengan mudah menyebabkan pengendali besar-besaran, kemungkinan besar karena Anda akan perlu melawan kerangka kerja atau menemukan kembali roda sesekali.

Singkatnya, bukan ide yang bagus. Selain itu, lebih sering daripada tidak, itu adalah gejala kurang pengalaman atau kecerobohan. Mengikuti "Prinsip Tanggung Jawab Tunggal" tampaknya juga sangat sulit dalam situasi ini—hanya dugaan yang berpendidikan.

Mendekati sumber daya di pengontrol Anda dengan tenang, membuat hidup Anda jauh lebih mudah dan aplikasi Anda juga lebih mudah dirawat—yang menambah stabilitas keseluruhan aplikasi Anda. Pikirkan tentang menangani sumber daya dengan tenang dari perspektif siklus hidup suatu objek. Anda membuat, memperbarui, menampilkan (satu atau koleksi), memperbarui dan menghancurkannya.

Untuk sebagian besar kasus, ini akan melakukan pekerjaan. FYI, tindakan new dan edit tidak benar-benar bagian dari REST—itu lebih seperti versi yang berbeda dari aksi show, membantu Anda menyajikan tahapan berbeda dalam siklus hidup sumber daya. Secara keseluruhan, tujuh tindakan pengontrol standar ini memberi Anda semua yang Anda butuhkan untuk mengelola sumber daya di pengontrol Anda. Keuntungan besar lainnya adalah pengembang Rails lain yang bekerja dengan kode Anda akan dapat menavigasi pengontrol Anda lebih cepat.

Mengikuti garis bantuan keren yang tenang, ini juga termasuk cara Anda memberi nama controller Anda. Nama sumber daya yang Anda kerjakan harus dicerminkan di objek pengontrol.

Misalnya, memiliki MissionsController yang menangani sumber daya selain benda-benda @mission adalah bau sesuatu yang tidak aktif. Ukuran semata-mata controller seringkali juga merupakan hadiah mati yang REST diabaikan. Jika Anda menjumpai pengontrol besar yang menerapkan banyak metode khusus yang tidak sesuai dengan konvensi, itu bisa menjadi strategi yang sangat efektif untuk membaginya menjadi beberapa pengontrol berbeda yang memiliki tanggung jawab yang terfokus—dan pada dasarnya hanya mengelola satu sumber daya tunggal sambil tetap berpegang pada gaya tenang. Pisahkan mereka secara agresif dan Anda akan lebih mudah menyusun metode mereka dengan cara Rails.

Rat’s Nest Resources

Lihat contoh berikut dan tanyakan pada diri sendiri apa yang salah dengan ini:

Nested AgentsController

app/controllers/agents_controller.rb

Di sini kami memeriksa apakah kami memiliki rute bersarang yang memungkinkan kami memperoleh id objek @mission. Jika demikian, kami ingin menggunakan objek terkait untuk mendapatkan agents dari itu. Kalau tidak, kami akan mengambil daftar semua agen untuk tampilan. Terlihat tidak berbahaya, terutama karena masih ringkas, tetapi ini merupakan awal dari sarang tikus yang berpotensi jauh lebih besar.

Nested Routes

Tidak ada yang tumpul tentang rute bersarang di sini. Secara umum, tidak ada yang salah dengan pendekatan ini. Hal yang harus kita perhatikan adalah bagaimana pengontrol menangani bisnis ini—dan sebagai konsekuensinya, bagaimana pandangan perlu beradaptasi dengannya. Tidak benar-benar bersih, seperti yang Anda lihat di bawah.

Lihat Dengan Persyaratan Yang Tidak Perlu

app/views/agents/index.html.erb

Mungkin juga tidak terlihat seperti masalah besar, saya mengerti. Tingkat kompleksitasnya bukan dunia nyata. Selain itu, argumennya lebih tentang berurusan dengan sumber daya dengan cara yang berorientasi objek dan tentang menggunakan Rails untuk keuntungan Anda sepenuhnya.

Saya kira ini adalah kasus kecil tentang tanggung jawab tunggal. Itu tidak benar-benar melanggar ide ini terlalu buruk, meskipun kita memiliki objek kedua—@mission—untuk asosiasi yang masih ada. Tetapi karena kami menggunakannya untuk mendapatkan akses ke agen tertentu, ini sama sekali tidak apa-apa.

Percabangan adalah bagian yang tidak elok dan kemungkinan besar akan menyebabkan keputusan desain yang buruk—baik dalam pandangan maupun pengontrol. Membuat dua versi @agents dengan metode yang sama adalah pelaku di sini. Saya akan mempersingkat, ini bisa keluar dari tangan dengan sangat cepat. Setelah Anda mulai mengumpulkan sumber daya seperti ini, kemungkinan besar tikus baru akan segera berkeliaran.

Dan pandangan di atas juga membutuhkan persyaratan yang beradaptasi dengan situasi ketika Anda memilikinya @agents yang terkait dengan sebuah @mission. Seperti yang dapat Anda lihat dengan mudah, sedikit kecerobohan dalam pengontrol Anda dapat menyebabkan tampilan membengkak yang memiliki lebih banyak kode daripada yang dibutuhkan. Mari kita coba pendekatan lain. Waktu pembasmi!

Pengontrol terpisah

Alih-alih bersarang sumber daya ini, kita harus memberikan masing-masing versi dari sumber daya ini pengendali khas dan fokusnya masing-masing—satu pengendali untuk "sederhana", agen yang tidak diuji dan satu untuk agen yang terkait dengan misi. Kita dapat mencapai ini melalui namespacing salah satunya di bawah folder /mission.

app/controllers/missions/agents_controller.rb

Dengan membungkus pengontrol ini di dalam sebuah modul, kita dapat menghindari mewarisi AgentsController dua kali dari ApplicationController. Tanpa itu, kita akan mengalami kesalahan seperti ini: Unable to autoload constant Missions::AgentsController. Saya pikir modul adalah harga kecil yang harus dibayar untuk membuat Rails autoloading bahagia. AgentsController kedua dapat tetap di file yang sama seperti sebelumnya. Sekarang hanya berurusan dengan satu sumber daya yang mungkin dalam index—menyiapkan semua agen tanpa misi yang ada.

app/controllers/agents_controller.rb

Tentu saja, kita juga perlu menginstruksikan rute kita untuk mencari pengontrol dengan spasi nama baru ini jika agen dikaitkan dengan sebuah misi.

Setelah kami tentukan bahwa sumber daya bersarang kami memiliki pengontrol dengan spasi nama, kami siap. Saat kami melakukan rake routes, periksa di terminal, kami akan melihat bahwa kontroler baru kami ditempatkan di tempat yang sesuai dan kami harus pergi.

New Routes

Kami resource bersarang untuk agents sekarang benar diarahkan ke controllers/missions/agents_controller.rb dan setiap tindakan bisa mengurus agen yang merupakan bagian dari misi. Demi kelengkapan, mari kita lihat juga pandangan akhir kita:

Agen dengan misi

app/views/missions/agents/index.html.erb

Agen Tanpa Misi

app/views/agents/index.html

Baiklah, mari kita singkirkan sedikit duplikasi yang kita ulangi @agents juga. Saya membuat sebagian untuk membuat daftar agen dan memasukkannya ke direktori shared baru di bawah views.

app/views/shared/_agents.html.erb

Tidak ada yang baru atau mengejutkan di sini, tetapi pandangan kami sekarang lebih KERING.

Agen Dengan Misi

app/views/missions/agents/index.html.erb

Agen Tanpa Misi

app/views/agents/index.html

Dope!

Pikiran terakhir

Saya pikir jika Anda sebagai pemula dapat menghindari AntiPatterns ini di controller Anda, Anda memulai dengan sangat baik. Masih banyak yang harus dipelajari untuk Anda dalam hal ini, tetapi berikan waktu, itu bukan hal yang mudah atau semalam. Di sisi lain, jika Anda haus akan lebih banyak dan ingin menjelajahi teknik yang lebih maju, tentu saja saya mendukung semuanya. Jangan biarkan diri Anda putus asa dengan tag nama "lanjutan".

Luangkan waktu Anda, bersenang-senang, dan jangan frustrasi jika Anda perlu mengunjungi kembali topik tersebut karena Anda belum memiliki semua potongan puzzle yang ada. Jika Anda masih awal dalam pengembangan game dan sudah mulai bermain dengan pola desain, saya yakin Anda jauh di depan permainan dan telah membuat keputusan yang tepat.

Jangan menunggu, dan keluar dari zona nyaman Anda untuk sedikit meregangkan materi abu-abu Anda.

Advertisement
Advertisement
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.