Halo semuanya. Saya ingin mengaku di hadapan Anda dan memberi tahu Anda sedikit tentang apa yang saya rasakan ketika saya berkembang di Laravel. Tidak, jangan berpikir tentang hal itu, saya suka kerangka ini dan saya sangat berterima kasih kepada tim yang menciptakannya dan mendukungnya, mereka melakukan pekerjaan yang sangat keren dan, menurut saya, Laravel adalah kelanjutan terbaik dari Symfony, tidak kurang disukai oleh saya.
Saya suka kode bodoh. Bodoh dalam arti bahwa bahkan setelah 10 tahun, jika pelanggan meminta Anda untuk mengubahnya, Anda dapat melakukan ini tanpa mempelajari keseluruhan logika, bahkan setelah mengejar pihak perusahaan pada hari Jumat, tanpa melanggar apa pun dalam kode lama. Dan bodoh dalam arti bahwa Anda tidak perlu melakukan upaya kognitif untuk memahaminya. Tetapi ada satu solusi arsitektur dalam Laravel Eloquent ORM yang membuat saya menangis. Menarik? Datanglah ke bawah kucing.
Orang-orang pintar telah menemukan segalanya untuk kita sejak lama: OOP, Pola Desain, SOLID, DDD, dan kata-kata menakutkan lainnya yang membuatmu sangat takut di awal, dan kemudian menerapkannya pada firasat.
Ini saya suka Laravel dan Symfony. Mereka memungkinkan Anda untuk menulis kode yang paling bodoh dan aman langsung dari kotak. Ya Masing-masing dari mereka memiliki kekurangannya ... Tetapi di Laravel ada satu yang paling mengganggu saya. Ini menggunakan Pola Rekaman Aktif (AR) untuk bekerja dengan model.
Sebagai permulaan, sedikit tentang pola ini. Tentang apa semua ini? Untuk memahami, Anda harus pergi ke induk dari desain aplikasi ini - pola Repositori. Pola ini adalah koleksi. Kumpulan entitas (Entitas) yang dapat mengambil, memodifikasi, menyimpan, menghapus, secara umum, mengelolanya di lokasi penyimpanan abstrak. Dalam 90 dari 100 persen kasus, lokasi penyimpanan ini adalah berbagai database. Tetapi mungkin ada sistem file, dan semacam cache, dan bahkan API eksternal.
Pendekatan ini sepenuhnya konsisten dengan prinsip tanggung jawab bersama dan pendekatan DDD. Selain itu, berkat pendekatan ini, konektivitas yang lemah diimplementasikan - kami tidak peduli bagaimana tepatnya aplikasi disimpan, kami bekerja dengan Entity ketika kami ingin bekerja secara langsung dengan representasi objek dari data dan bekerja dengan Repository ketika kami perlu berinteraksi dengan repositori.
Tetapi Laravel memutuskan untuk menggunakan AR, yang tidak dapat disangkal keren dan sangat nyaman ketika Anda perlu membuat prototipe cepat, tetapi itu menjadi sakit kepala yang luar biasa ketika Anda perlu berinteraksi dengan beberapa sumber data dan beroperasi dengan mereka dalam sistem.
AR adalah pola yang memetakan Entitas dan Repositori menjadi satu Model. Artinya, suatu objek menjadi representasi dari catatan tertentu dalam database. Dan ... apa? Apa yang menyebabkan hal ini dan mengapa itu sangat menjengkelkan?
Pertama, kita melanggar prinsip tanggung jawab bersama yang sama - logika bekerja dengan repositori di satu tempat, dan logika bekerja dengan entitas di tempat lain. Ini penting, karena dalam kerangka sistem saya, saya tidak ingin mentransfer garis dari database dalam representasi objek melalui rantai panggilan. Saya ingin lulus model. Saya seharusnya tidak peduli bagaimana hasilnya, perubahan dan bertahan. Saya perlu memiliki metode-metode yang memungkinkan Anda untuk berinteraksi hanya dengan model, dan bukan dengan baris dalam database.
Kedua, kita tidak bisa (sebagai konsekuensi dari kenyataan bahwa lapisan Persistent - lapisan penyimpanan - terhubung dengan lapisan entitas), cukup mengubah lokasi penyimpanan model. Ya, kami dapat melakukan ini dalam konfigurasi, mengubahnya segera untuk semua orang, dalam database yang didukung. Atau ubah hanya untuk model tertentu (dengan semua ini, kami tidak menghapus metode pembuat kueri apa pun, karena Anda tidak dapat menyingkirkan metode kelas dasar) dan mengalami banyak kemungkinan kesalahan dalam kode atau, Tuhan melarang, jika orang lain akan mendukung (dan ini terjadi setiap saat).
Ketiga Saya ingin menguji entitas saya. Saya ingin membuatnya yakin bahwa perubahan yang saya buat tidak akan merusak logika bisnis saya. Dan, seperti yang ditunjukkan oleh latihan, dalam kasus AR Anda tidak dapat melakukan ini, karena prinsip jahat dari tanggung jawab tunggal telah dilanggar! Meskipun di sini saya agak tidak jujur. Menguji model adalah mungkin, hanya ... Sedikit rumit.
Namun demikian, tidak mungkin untuk tidak mengatakan tentang keuntungan dari pola ini. Meskipun kelebihannya adalah "cepat, sederhana, tanpa ragu-ragu." Dengan menggabungkan dua pola yang dekat dalam logika dengan tindakan mereka dan terus-menerus digunakan bersama, kami mendapat alat yang nyaman yang sedikit mengurangi jumlah kode (dalam arah kompleksitas, apakah kita ingat "kode bodoh"?). Hal ini juga memungkinkan Anda untuk menyingkirkan masalah yang tidak perlu pada tahap pembentukan MVP, yang wajib (praktik menunjukkan bahwa ini jarang terjadi, tetapi masih) direncanakan untuk menulis ulang. Ini memungkinkan Anda untuk mengalihkan pikiran dari pertanyaan "bagaimana kita melakukan" ke pertanyaan "apa yang kita lakukan", yaitu, menyingkirkan pertanyaan yang tidak perlu tentang teknologi dan beralih ke logika bisnis.
Apa kesimpulan yang saya dapatkan selama bertahun-tahun menggunakan Laravel Eloquent ORM? Rekam aktif kejahatan dalam daging? Tidak, ini adalah alat paling keren untuk beberapa situasi, terutama untuk tahap ketika Anda menulis aplikasi sederhana atau prototipe aplikasi semacam itu. Tetapi ini adalah hal yang mustahil untuk bekerja ketika aplikasi Anda tumbuh dan Anda harus bekerja dengan sejumlah besar sumber data, menulis kode dengan cakupan uji 100%, dan masalah besar dimulai.
Ya, chip baru sedang ditemukan ( Pengemudi truk ?), Tapi mari kita lanjutkan trik. Tapi saya masih ingin sedikit lebih banyak kebebasan dari kerangka kerja, terutama karena sangat baik untuk banyak orang!