Dalam API kami, kami memiliki beberapa tipe data pusat yang perlu "didekorasi" (dapat dikatakan) setelah pengambilan dari database dengan nilai yang dihitung. Basis data diakses melalui ORM yang mengikuti dinamika Table / Entity yang sangat terinspirasi oleh lapisan basis data CakePHP 3, di mana objek Table digunakan sebagai perantara antara database dan aplikasi yang mengambil dan membagikan baris sebagai instance objek model. Jadi alih-alih hanya mengambil data dari database dan mengembalikan baris-baris itu, kita perlu memproses ulang data yang dikembalikan sebelum benar-benar dapat digunakan. Berikut adalah beberapa kasus penggunaan yang muncul untuk lebih menjelaskan apa yang saya maksud:
- Objek memiliki nilai numerik yang diterjemahkan ke label yang mudah digunakan (biasanya ini adalah logika yang saya akan tetap murni pada klien, tetapi untuk alasan keamanan bisnis beberapa data ini perlu disimpan di server saja, diakui sedikit dari kasus tepi)
- Objek harus memiliki nilai peringkat terkait yang ditarik dari peringkat yang baru ditambahkan
- Berdasarkan kombinasi nilai yang dihitung seperti ini dan nilai yang disimpan, objek jadwal kompleks dibangun
Sendiri, semua ini secara individual sebenarnya cukup mudah dilakukan dengan map()operasi sederhana atas hasil yang dikembalikan. Hal yang sama berlaku untuk ketika Anda ingin beberapa nilai yang dihitung, Anda bisa melakukan lebih banyak operasi peta untuk menghitung dan menambahkan bidang-bidang tersebut jika diperlukan.
Yang mengatakan, pendekatan ini memiliki dua kelemahan utama:
- Ini berarti bahwa Anda perlu melakukan langkah tambahan pasca-pemrosesan di mana pun Anda ingin bekerja dengan nilai-nilai yang dihitung ini, yang tidak terlalu KERING
- Beberapa transformasi ini bergantung pada transformasi lain yang dilakukan terlebih dahulu, jika tidak mereka tidak memiliki data yang tersedia untuk dikerjakan
Untuk menangani keduanya, saya telah berpikir bahwa pendekatan terbaik adalah dengan memindahkan kode ini ke dalam ORM, kemudian memodifikasi ORM sehingga antarmuka akan (secara eksternal) memungkinkan akses ke bidang virtual yang dihitung dengan cara yang sama seperti yang berhubungan dengan kolom basis data . Secara internal ia kemudian dapat memetakan bidang-bidang virtual ini ke fungsi transformasi, dan secara internal menentukan potensi transformasi ketergantungan yang diperlukan untuk menyelesaikan masalah kedua.
(Sebagai tambahan, saya bertanya-tanya apakah ini juga menghilangkan perlunya baris yang dikembalikan menjadi objek aktual sebagai lawan hash sederhana. Saat ini setiap baris membuat objek baru dengan data bidang yang ditetapkan di atasnya, tetapi jika semua perhitungan atau modifikasi data dipindahkan dari model maka objek hanya menjadi sekumpulan properti - sebuah hashmap, pada dasarnya, tanpa logika internal sendiri. Yang mungkin sebenarnya bukan hal yang buruk menurut saya)