Model per tabel basis data?

Saya menggunakan codeigniter, dan menemukan diri saya dalam situasi yang sama di mana saya telah mengulangi metode Model. Saya membuat Model per Pengendali. Tapi saya akan membuat Model per tabel database dianggap praktik yang baik? Dengan begitu metode tidak ditulis dua kali.

Alih-alih Model per Pengendali atau Beberapa Model kecil yang dibagikan.

Contoh jika saya memiliki metode model get_user ($ user_id) saya bisa menulisnya di users_models.php ...

Salah satu kelemahan saya melihat ini adalah bahwa saya mungkin harus memanggil beberapa model, bukan hanya controllername_models.php.

Bisakah memuat beberapa model di mana beberapa metode mungkin tidak digunakan dari pengontrol mempengaruhi kinerja dan kecepatan? Apa yang bisa menjadi cara terbaik untuk mengatasi ini?

Catatan: Ada pertanyaan serupa, tetapi tidak mencakup dasar Model per tabel basis data.

Saya mengatakan bahwa model per tabel hanya menciptakan kembali database Anda dalam struktur kelas. Ini dikenal sebagai model anemia dan dianggap sebagai anti-pola. Itu karena kelas dimaksudkan untuk memiliki data dan perilaku. Jika Anda membatasi model Anda ke satu tabel, di mana Anda meletakkan kode (perilaku) yang perlu berurusan dengan data dan perilaku dari beberapa tabel? Pengontrol Anda akan membutuhkan model yang menggunakan satu atau lebih dari model "tabel" ini ... Jadi, selain dari aplikasi yang paling dasar, Anda mendapatkan sedikit jika ada sesuatu dari pendekatan ini.

Secara umum Anda harus membuat model Anda bukan per tabel atau per controller tetapi per objek bisnis. Kadang-kadang mungkin hubungan 1: 1 dengan struktur tabel Anda atau dengan pengontrol Anda, tetapi tidak perlu.

Dalam contoh Anda, Anda mungkin memiliki satu users_modelkelas yang dipanggil dari beberapa pengontrol. Ini bagus dan terkadang bahkan diinginkan. Namun dalam kebanyakan kasus users_modelkelas akan mendapatkan datanya dari beberapa tabel.
Sebagai contoh, last_login_dateproperti users_modelkelas dapat ( tidak harus ) diperoleh dari user_audittabel terpisah yang memiliki hubungan satu-ke-banyak dengan userstabel utama .

Dan saya akan mengatakan jika Anda memiliki satu tabel SQL per objek bisnis maka kemungkinan besar struktur database Anda tidak dinormalisasi.

Saya sebagian besar setuju dengan jawaban Dime bahwa Anda ingin membuat model Anda per objek bisnis - masalah yang coba dipecahkan oleh bisnis harus mengarahkan bagaimana Anda membuat kelas model. Dalam praktiknya, saya telah menemukan bahwa membuat satu model per tabel adalah tempat yang baik untuk memulai. Skema yang dirancang dengan tepat cenderung meniru proses bisnis yang Anda perlu model dalam kode aplikasi - juga disebut Model Domain.

Menggunakan lapisan Object / Relational Mapping berguna sehingga Model Domain Anda berisi hubungan yang sama dengan skema database tanpa perlu panggilan berulang ke lapisan akses data. Lihat Eloquent untuk PHP sebagai contoh. Skema dan Model Domain harus dirancang untuk mendukung proses bisnis.

Ini mengarah ke bagian pertama dari jawaban Marjan Venema:

Saya mengatakan bahwa model per tabel hanya menciptakan kembali database Anda dalam struktur kelas. Ini dikenal sebagai model anemia dan dianggap sebagai anti-pola.

Sebuah anemia Domain Model adalah anti-pola. "Model per tabel" seperti yang disarankan Venema dapat dilihat sebagai "membuat ulang basis data Anda," namun benar-benar salah untuk mengatakan ini saja adalah Model Domain Anemik.

Dari Martin Fowler:

Gejala dasar dari Model Domain Anemik adalah bahwa pada blush on pertama terlihat seperti hal yang nyata. Ada objek, banyak yang dinamai dengan kata benda di ruang domain, dan objek ini terhubung dengan hubungan dan struktur kaya yang dimiliki oleh model domain yang sebenarnya. Tangkapan datang ketika Anda melihat perilaku, dan Anda menyadari bahwa hampir tidak ada perilaku pada benda-benda ini, membuat mereka sedikit lebih dari sekantong getter dan setter.

(penekanan, milikku)

Faktor kunci dalam model domain anemia adalah kurangnya perilaku, atau metode, pada kelas Model Domain.

Itu karena kelas dimaksudkan untuk memiliki data dan perilaku. Jika Anda membatasi model Anda ke satu tabel, di mana Anda meletakkan kode (perilaku) yang perlu berurusan dengan data dan perilaku dari beberapa tabel?

Sekali lagi, Anda bisa, dan harus, menempatkan perilaku di Model Domain Anda, bahkan jika mereka hanya memetakan ke satu tabel. Perilaku yang memengaruhi banyak tabel benar-benar memengaruhi banyak objek yang terjadi memetakan ke beberapa tabel. Domain Driven Design adalah pendekatan untuk masalah yang persis sama yang disebutkan Venema: "di mana Anda meletakkan kode (perilaku) yang perlu berurusan dengan data dan perilaku dari beberapa tabel?"

Dan jawabannya adalah Root Agregat . Martin Fowler menyatakan:

Agregat adalah pola dalam Desain Berbasis Domain. Agregat DDD adalah sekelompok objek domain yang dapat diperlakukan sebagai satu unit. Contoh mungkin pesanan dan item barisnya, ini akan menjadi objek yang terpisah, tetapi berguna untuk memperlakukan pesanan (bersama dengan item barisnya) sebagai agregat tunggal.

(penekanan, milikku)

"Cluster objek domain" juga dapat dilihat sebagai "Model Domain yang memetakan ke beberapa tabel." Perilaku yang memengaruhi banyak tabel harus didefinisikan pada Agregat Root - Kelas yang merangkum "hal" yang memengaruhi banyak tabel atau objek:

Lagi, dari Martin Fowler:

Agregat akan sering berisi koleksi mutliple, bersama dengan bidang sederhana.

Untuk menjawab pertanyaan awal OP:

... akan membuat Model per tabel basis data dianggap praktik yang baik? Dengan begitu metode tidak ditulis dua kali.

Saya akan mengatakan ini adalah tempat yang baik untuk memulai, tetapi perlu diketahui bahwa skema dan model objek Anda tidak harus cocok dengan 100%. Model objek harus lebih mementingkan penerapan dan penegakan aturan bisnis. Skema harus lebih fokus pada penyimpanan data bisnis dengan cara yang modular dan dapat diskalakan.

Sebuah model per kontroler tidak akan menjadi latihan yang bagus, meskipun ada variasi model yang disebut View Model yang tidak fit ke dalam lapisan Controller. Sebuah View Model adalah reorganisasi Model Domain untuk menyesuaikan jenis tertentu layar, baik itu halaman web atau bentuk dalam aplikasi GUI.