Sebelum saya menjawab pertanyaan, saya pikir beberapa latar belakang sudah beres.
Inti Masalah
Setelah bertahun-tahun mewawancarai dan merekrut pengembang, saya telah belajar dua hal:
Sebagian besar pengembang hanya memiliki sedikit pengalaman dalam desain basis data.
Saya telah melihat korelasi longgar antara mereka yang tidak mengerti database dan mereka yang membenci ORM.
(Catatan: dan ya, saya tahu ada orang yang sangat paham database yang membenci ORM)
Ketika orang-orang tidak mengerti mengapa kunci asing penting, mengapa Anda tidak menanamkan nama produsen di itemmeja, atau mengapa customer.address1, customer.address2dan customer.address3bidang yang bukan ide yang baik, menambahkan ORM untuk membuatnya lebih mudah bagi mereka untuk bug database yang menulis tidak akan membantu apa pun.
Alih-alih, dengan database yang dirancang dengan benar dan case use OLTP, ORM adalah emas. Sebagian besar pekerjaan kasar hilang dan dengan alat-alat seperti DBIx :: Class :: Schema :: Loader , saya bisa beralih dari skema database yang baik untuk bekerja kode Perl dalam hitungan menit. Saya akan mengutip Aturan Pareto dan mengatakan bahwa 80% masalah saya telah diselesaikan dengan 20% pekerjaan, tetapi dalam kenyataannya, saya menemukan manfaat yang bahkan lebih besar dari itu.
Menyalahgunakan Solusi
Alasan lain beberapa orang membenci ORM adalah karena mereka akan membiarkan abstraksi bocor. Mari kita perhatikan kasus umum aplikasi web MVC. Ini adalah sesuatu yang biasa kita lihat (pseudo-code):
GET '/countries/offices/$company' => sub {
my ( $app, $company_slug ) = @_;
my $company = $app->model('Company')->find({ slug => $company_slug })
or $app->redirect('/');
my $countries = $app->model('Countries')->search(
{
'company.company_id' => $company->company_id,
},
{
join => [ offices => 'company' ],
order_by => 'me.name',
},
);
$app->stash({
company => $company,
countries => $country,
});
}
Orang-orang menulis rute pengontrol seperti itu dan menepuk diri mereka sendiri di belakang, berpikir itu adalah kode yang baik dan bersih. Mereka akan kaget pada hard-coding SQL di controller mereka, tetapi mereka telah melakukan sedikit lebih banyak daripada mengekspos sintaks SQL yang berbeda. Kode ORM mereka perlu didorong ke dalam model dan kemudian mereka dapat melakukan ini:
GET '/countries/offices/$company' => sub {
my ( $app, $company_slug ) = @_;
my $result = $app->model('Company')->countries($company_slug)
or $app->redirect('/');
$app->stash({ result => $result });
}
Anda tahu apa yang terjadi sekarang? Anda telah mengenkapsulasi model Anda dengan benar, Anda belum mengekspos ORM, dan kemudian, ketika Anda menemukan bahwa Anda bisa mengambil data itu dari cache alih-alih basis data, Anda tidak perlu mengubah kode pengontrol Anda (dan itu lebih mudah untuk menulis tes untuk itu dan menggunakan kembali logika).
Pada kenyataannya, yang terjadi adalah orang-orang membocorkan kode ORM mereka di seluruh pengontrol (dan pandangan) mereka dan ketika mereka mengalami masalah skalabilitas, mereka mulai menyalahkan ORM daripada arsitektur mereka. ORM mendapat rap buruk (saya melihat ini berulang kali untuk banyak klien). Alih-alih, sembunyikan abstraksi itu sehingga ketika Anda benar-benar mencapai batas ORM, Anda dapat memilih solusi yang sesuai untuk masalah Anda alih-alih membiarkan kode digabungkan dengan erat ke ORM sehingga Anda terikat dengan babi.
Pelaporan dan Batasan Lainnya
Seperti yang dijelaskan oleh Rob Kinyon di atas, pelaporan cenderung menjadi kelemahan dalam ORM. Ini adalah himpunan bagian dari masalah yang lebih besar di mana SQL atau SQL rumit yang mencakup beberapa tabel kadang-kadang tidak berfungsi dengan baik dengan ORM. Sebagai contoh, kadang-kadang ORM memaksa tipe join yang tidak saya inginkan dan saya tidak tahu cara memperbaikinya. Atau mungkin saya ingin menggunakan petunjuk indeks di MySQL, tetapi itu tidak mudah . Atau kadang-kadang SQL sangat rumit sehingga akan lebih baik untuk menulis SQL daripada abstraksi yang disediakan.
Ini adalah bagian dari alasan saya mulai menulis DBIx :: Class :: Report . Sejauh ini berfungsi dengan baik dan memecahkan sebagian besar masalah yang dialami orang di sini (asalkan tidak masalah dengan antarmuka hanya baca). Dan meskipun itu tampak seperti tongkat penyangga, pada kenyataannya, selama Anda tidak membocorkan abstraksi Anda (seperti yang dijelaskan di bagian sebelumnya), itu membuatnya bekerja dengan DBIx::Classlebih mudah.
Jadi Kapan Saya Memilih DBIx :: Kelas?
Bagi saya, saya akan memilih sebagian besar waktu ketika saya membutuhkan antarmuka ke database. Saya telah menggunakannya selama bertahun-tahun. Namun, saya mungkin tidak memilihnya untuk sistem OLAP, dan programmer yang lebih baru pasti akan berjuang dengan itu. Juga, saya sering menemukan saya perlu meta-pemrograman dan sementara DBIx::Classmenyediakan alat-alat, mereka sangat tidak terdokumentasi.
Kunci untuk menggunakan DBIx::Classdengan benar sama dengan kebanyakan ORM:
Jangan bocor abstraksi.
Tulis tes terkutukmu.
Ketahui cara drop down ke SQL, sesuai kebutuhan.
Pelajari cara menormalkan basis data.
DBIx::Class, begitu Anda mempelajarinya, akan menangani sebagian besar tugas berat Anda dan menjadikannya mudah untuk menulis aplikasi dengan cepat.