Apa jenis proyek pengembangan Web yang mendapat manfaat dari menggunakan ORM?

10

Saya akan mulai dengan mengatakan bahwa saya telah melakukan 95% pekerjaan basis data saya menggunakan SQL. Baru-baru ini, saya melakukan beberapa investigasi terhadap berbagai ORM, seperti NHibernate dan Doctrine.

Saya bisa melihat keuntungan dari tidak perlu tahu banyak SQL dan portabilitas database yang disediakan ORM. Tapi saya juga bisa melihat bahwa mengetahui SQL akan membuat bekerja dengan ORM lebih efektif dan saya hanya bisa memikirkan satu kali dalam karir saya bahwa perubahan terbesar aplikasi adalah vendor database.

Karena saya sangat nyaman menulis SQL dan tampaknya tidak menyadari manfaat yang sering diajarkan dari menggunakan ORM, pertanyaan saya kepada pengguna ORM yang berat adalah ini:

Apa jenis proyek pengembangan Web yang paling diuntungkan dari menggunakan ORM?

— Fred Wilson
sumber

3

Jawabannya adalah "Semuanya." Tapi itu mungkin bukan yang ingin Anda ketahui. Anda mungkin ingin mempersempit pertanyaan Anda untuk menanyakan beberapa informasi yang lebih spesifik.

— S.Lott

1

Bagi saya, SQL saat ini lebih mudah dibuat tetapi itu hanya karena aklimasi saya (atau ketidaktahuan). Saya pernah membaca bahwa ORM tidak selalu merupakan pilihan terbaik karena lebih lambat dari SQL normal; namun, banyak pengembang menyatakan bahwa ini biasanya tidak penting. Saya sebagian besar ingin tahu tentang proyek yang paling cocok untuk ORM. Saya dapat melihat sebagian besar jawaban mungkin adalah "semuanya", dan itu bagus juga. Saya tidak mencari jawaban spesifik. :)

— Fred Wilson

Jika Anda tidak meminta detail lebih lanjut, Anda tidak akan belajar banyak.

— S.Lott

5

(Hampir) semua aplikasi mendapat manfaat dari ORM.

Pertama, saya tidak setuju dengan kelebihan yang Anda daftarkan untuk ORM .

Menggunakan ORM tidak selalu berarti Anda tidak perlu tahu SQL. Pengetahuan tentang SQL akan membantu memahami apa yang sebenarnya dilakukan alat ORM, yang sangat berguna selama debugging. Selain itu, SQL sebenarnya mungkin diperlukan untuk mengembangkan kueri kompleks yang berada di luar kemampuan ORM pilihan Anda.
Dan seperti yang Anda katakan, portabilitas jarang menjadi perhatian dalam kehidupan nyata.

Sebaliknya, manfaat nyata dari ORM adalah:

ORM menghemat waktu programmer karena menghemat banyak penulisan logika CRUD dalam SQL
banyak ORM termasuk logika caching yang kompleks dll. yang sulit untuk ditulis dan didebug. Selain menghemat waktu, ini dapat meningkatkan keandalan dan pemeliharaan aplikasi Anda (atau setidaknya menghemat waktu yang Anda perlukan untuk mencapai hasil yang sama)
ORM terbaik memiliki komunitas pengguna yang secara aktif mengembangkan, memelihara, dan mendukung produk. Komunitas di sekitar SQL kustom, paling banter, agak kurang fokus pada masalah yang perlu kita selesaikan.

Saat Anda berkomentar, satu sisi ORM adalah hilangnya kinerja. Namun, ini biasanya dapat diimbangi dengan menghabiskan lebih banyak perangkat keras.

Biasanya, waktu programmer lebih mahal daripada perangkat kerasnya, jadi ORM secara umum merupakan pilihan yang baik alih-alih mengkode tangan SQL.

ORM adalah yang terbaik untuk aplikasi dengan banyak logika database CRUD yang cukup sederhana. ORM kurang efektif untuk :

Aplikasi yang membutuhkan sedikit / tanpa akses basis data.
Aplikasi yang sebagian besar tergantung pada permintaan kompleks dan logika CRUD sangat sedikit sederhana
Situasi di mana kinerja sangat penting, tetapi di mana tidak ada kemungkinan menggunakan perangkat keras yang lebih cepat

Dalam pengalaman saya, situasi ini jarang terjadi. Karena itu jawabanku.

— Kramii
sumber

"Menggunakan ORM tidak selalu berarti Anda tidak perlu tahu SQL." - Benar sekali. Salah satu keuntungan yang saya lihat di lingkungan tim adalah kita dapat memusatkan keahlian SQL sehingga tidak semua pengembang yang bekerja di lapisan bisnis harus menjadi ahli.

— Fred Wilson

1

Untuk kueri yang kompleks, Anda selalu dapat kembali ke SQL dan menulis kueri SQL.

— harsimranb

4

Saya nyaman menulis SQL juga. Saya juga jauh lebih nyaman tidak harus menulis SQL sama sekali, serta tidak khawatir tentang koneksi, pemutusan, pengumpulan, dll ke database.

Jadi .. saya akan menjawab negatif pertanyaan Anda. Satu-satunya proyek pengembangan web yang TIDAK mendapat manfaat dari ORM adalah yang tidak berbicara sama sekali dengan database. Yang saya percaya adalah minoritas (jika ada).

— Otávio Décio
sumber

+1: Saya juga menganggap diri saya sangat mahir di sql, tetapi masih lebih suka OR / M. Sebenarnya saya akan mengatakan Anda pasti harus memiliki pegangan pada sql untuk memanfaatkan OR / M, jika tidak, jika abstraksi bocor, Anda tidak akan pernah menemukan masalah. "tidak perlu tahu banyak SQL" bukan fitur. Bagi saya ini semua tentang peningkatan produktivitas dan membuat kompiler menemukan masalahnya, bukan runtime, dan OR / M (terutama yang berbasis generik / linq baru yang hebat pada saat itu).

— Brook

@ Brook - Saya sepenuh hati setuju. Menggunakan OR / M tidak berarti bahwa pengetahuan SQL adalah opsional.

— Otávio Décio

2

Berdasarkan pengalaman saya dengan ASP.NET WebForms saya akan mengusulkan bahwa proyek web menggunakan kerangka kerja web stateful paling menguntungkan dari menggunakan ORM.

Dengan kerangka stateful markup dihasilkan secara otomatis di belakang layar, berdasarkan hirarki kontrol server yang aktif. Sangat menggoda untuk membuat kontrol-kontrol itu dimuat dan mempertahankan statusnya secara otomatis ke database. Di sinilah ORM membantu.

Anda mengurutkan abstrak dari akhir pipeline (HTML output) dan secara alami mengundang untuk berurusan dengan permulaan (sumber data) dengan cara yang sama sehingga Anda hanya tetap berada dalam logika bisnis Anda dalam kode aplikasi.

Bukannya saya tidak mengatakan ini adalah cara yang baik untuk melakukan sesuatu. Itu hanya tempat ORM cocok secara alami.

2

Dalam aplikasi di mana Anda memiliki model objek yang besar dan sangat terhubung, ORM menyelamatkan Anda dari menulis gabungan yang sama berulang-ulang.

Manfaat lain adalah pemuatan malas, di mana Anda ingin api mengembalikan grafik objek di mana klien api hanya akan menggunakan subset dari grafik itu.

— Paul Sanwald
sumber

1

Saya yakin Anda mengacaukan ORM dengan DBAL .

Konsep yang Anda maksud adalah Database Abstraction Layer (DBAL) yang memungkinkan Anda untuk menulis "sql" portabel yang tidak tergantung pada sistem database yang mendasarinya.

ORM di sisi lain (yang (hampir?) Selalu dibangun di atas DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipedia)

Sederhananya, ORM memungkinkan Anda untuk mengkonversi data dari database datar menjadi representasi objek yang meningkat.

— Mendambakan
sumber

Terimakasih atas klarifikasinya. Alasan utama bagi saya untuk pindah ke ORM adalah untuk lebih fokus pada OOP dan menjauh dari menulis sebanyak SQL jika masuk akal untuk beberapa proyek.

— Fred Wilson

1

Proyek yang tidak mendapat manfaat dari ORM adalah:

yang tidak berorientasi objek;
yang tidak perlu bertahan data;
yang menggunakan DB berorientasi objek, jadi tidak perlu lapisan pemetaan tambahan;
yang menggunakan solusi NoSQL yang tidak berhubungan;

— vartec
sumber