Apakah ada alasan bagus untuk tidak menggunakan ORM? [Tutup]


107

Selama magang saya, saya telah menggunakan NHibernate untuk beberapa proyek kecil yang sebagian besar saya kodekan dan rancang sendiri. Sekarang, sebelum memulai beberapa proyek yang lebih besar, muncul diskusi tentang bagaimana merancang akses data dan apakah akan menggunakan layer ORM atau tidak. Karena saya masih dalam masa magang dan masih menganggap diri saya sebagai pemula dalam pemrograman perusahaan, saya tidak benar-benar mencoba mendorong menurut pendapat saya, yaitu menggunakan mapper relasional objek ke database dapat memudahkan pengembangan cukup banyak. Pembuat kode lain dalam tim pengembangan jauh lebih berpengalaman daripada saya, jadi saya pikir saya hanya akan melakukan apa yang mereka katakan. :-)

Namun, saya tidak sepenuhnya memahami dua alasan utama untuk tidak menggunakan NHibernate atau proyek serupa:

  1. Seseorang dapat membuat objek akses datanya sendiri dengan kueri SQL dan menyalin kueri tersebut dari Microsoft SQL Server Management Studio.
  2. Men-debug ORM bisa jadi sulit.

Jadi, tentu saja saya bisa membangun lapisan akses data saya dengan banyak SELECTdll, tetapi di sini saya kehilangan keuntungan dari gabungan otomatis, kelas proxy pemuatan lambat dan upaya pemeliharaan yang lebih rendah jika tabel mendapat kolom baru atau kolom mendapat berganti nama. (Memperbarui banyak SELECT, INSERTdan UPDATEkueri vs. memperbarui konfigurasi pemetaan dan mungkin memfaktorkan ulang kelas bisnis dan DTO.)

Selain itu, dengan menggunakan NHibernate, Anda dapat mengalami masalah yang tidak terduga jika Anda tidak memahami framework dengan baik. Bisa jadi, misalnya, mempercayai Table.hbm.xml tempat Anda menyetel panjang string untuk divalidasi secara otomatis. Namun, saya juga dapat membayangkan bug serupa dalam lapisan akses data berbasis kueri SqlConnection "sederhana".

Akhirnya, apakah argumen yang disebutkan di atas benar-benar alasan yang baik untuk tidak menggunakan ORM untuk aplikasi perusahaan berbasis database yang tidak sepele? Apakah mungkin ada argumen lain yang mungkin mereka / saya lewatkan?

(Saya mungkin harus menambahkan bahwa menurut saya ini seperti aplikasi berbasis .NET / C # "besar" pertama yang akan membutuhkan kerja tim. Praktik yang baik, yang terlihat cukup normal di Stack Overflow, seperti pengujian unit atau integrasi berkelanjutan, tidak -ada di sini sampai sekarang.)

Jawaban:


26

Ada ledakan pertumbuhan dengan ORM dalam beberapa tahun terakhir dan rekan kerja Anda yang lebih berpengalaman mungkin masih berpikir dalam mentalitas "setiap panggilan database harus melalui prosedur yang tersimpan".

Mengapa ORM mempersulit proses debug? Anda akan mendapatkan hasil yang sama baik itu berasal dari proc yang disimpan atau dari ORM.

Saya kira satu-satunya kerugian nyata yang dapat saya pikirkan dengan ORM adalah model keamanannya sedikit kurang fleksibel.

EDIT: Saya baru saja membaca ulang pertanyaan Anda dan sepertinya mereka menyalin dan menempelkan kueri ke dalam inline sql. Ini membuat model keamanan sama dengan ORM, jadi sama sekali tidak akan ada keuntungan atas pendekatan ini dibandingkan ORM. Jika mereka menggunakan kueri unparametrized maka itu sebenarnya akan menjadi risiko keamanan.


1
Lebih sulit untuk di-debug: Jika pengecualian muncul, Anda mungkin perlu mengetahui kerangka kerjanya daripada mengetahui pengecualian SqlConnection, dll.
hangy

4
Bukankah pengecualian sql menjadi bagian dari pengecualian ORM?
Giovanni Galbo

1
Ya, sebagian besar membungkus pengecualian, sehingga Anda masih akan bisa mendapatkan pengecualian berasal thorugh .inner
mattlant

Seperti yang saya katakan, saya tidak mengemukakan argumen itu. :) Tentu saja, pengecualian SQL yang sebenarnya harus berada di bawah jejak tumpukan. Seperti yang mungkin telah Anda baca dari pertanyaan saya, saya agak setuju dengan jawaban Anda, tetapi saya akan menunggu dengan menerimanya. Mungkin orang lain memiliki alasan yang sangat bagus untuk menentang ORM.
hangy

Bagaimana jika struktur database Anda sangat berbeda dari objek bisnis Anda. Bukankah itu akan mengubah semuanya menjadi overhead? memprogram pemetaan dengan xml, bukan hanya menyediakan fungsi yang diperlukan di sisi db dengan SP ...?
Uri Abramson

58

Jawaban singkatnya adalah ya, ada alasan yang sangat bagus. Faktanya ada beberapa kasus di mana Anda tidak bisa menggunakan ORM.

Contohnya, saya bekerja untuk lembaga keuangan perusahaan besar dan kami harus mengikuti banyak pedoman keamanan. Untuk memenuhi aturan dan regulasi yang diberikan kepada kami, satu-satunya cara untuk lulus audit adalah dengan menjaga akses data dalam prosedur yang tersimpan. Sekarang beberapa orang mungkin mengatakan itu hanya bodoh, tapi sejujurnya tidak. Menggunakan alat ORM berarti alat / pengembang dapat memasukkan, memilih, memperbarui atau menghapus apa pun yang dia inginkan. Prosedur tersimpan memberikan lebih banyak keamanan, terutama di lingkungan saat menangani data klien. Saya pikir ini adalah alasan terbesar untuk dipertimbangkan. Keamanan.


25
Saya pikir ini lebih merupakan batasan pustaka orm saat ini yang tidak mendukung prosedur tersimpan daripada batasan mendasar dalam atau pemetaan. Ada orm yang dapat menangani proc dan view yang disimpan dan ada banyak hal yang bisa dikatakan untuk solusi orm + stored procs.
Mendelt

4
Dalam kasus ORM yang baik, Anda harus bisa membuatnya tetap menggunakan SP (tentu saja, ini mengurangi banyak manfaat ...)
kͩeͣmͮpͥ ͩ

3
Topik mengapa SP tidak benar-benar memberikan keamanan lebih daripada ORM adalah topik yang digarap dengan baik. Ini hanya satu artikel yang membahasnya dengan baik: ayende.com/Blog/archive/2007/11/18/…
Tim Scott

1
Nah, di Sql Server 2005 tidak bisakah Anda hanya menetapkan skema dalam database hanya untuk lapisan ORM? Ataukah itu tidak cukup? Jika aplikasinya adalah aplikasi web, maka satu hal yang menghubungkan ke db. Keamanan kemudian diserahkan ke lapisan aplikasi.
Min

2
Tentu saja Anda dapat membatasi apa yang dapat dilakukan pengguna dengan ORM. Anda cukup mengatur pengaturan keamanan pengguna di SQL dan memberi mereka hak istimewa untuk memasukkan / memperbarui / menghapus apa yang Anda inginkan. Ini akan sama dengan menetapkan prioritas keamanan untuk prosedur tersimpan
Doctor Jones

55

Tempat yang tepat dari ORM

ORM berguna untuk mengotomatiskan 95% + kueri yang berlaku. Kekuatan khusus mereka adalah di mana Anda memiliki aplikasi dengan arsitektur model objek yang kuat dan database yang berfungsi baik dengan model objek tersebut. Jika Anda melakukan build baru dan memiliki keterampilan pemodelan yang kuat di tim Anda, Anda mungkin akan mendapatkan hasil yang bagus dengan ORM.

Anda mungkin memiliki beberapa pertanyaan yang lebih baik dilakukan dengan tangan. Dalam hal ini, jangan takut untuk menulis beberapa prosedur tersimpan untuk menangani ini. Meskipun Anda bermaksud untuk mem-port aplikasi Anda di beberapa platform DBMS, kode yang bergantung pada database akan menjadi minoritas. Ingatlah bahwa Anda perlu menguji aplikasi Anda pada platform apa pun yang ingin Anda dukung, sedikit upaya porting ekstra untuk beberapa prosedur tersimpan tidak akan membuat banyak perbedaan pada TCO Anda. Untuk perkiraan pertama, 98% portabel sama baiknya dengan 100% portabel, dan jauh lebih baik daripada solusi berbelit-belit atau berkinerja buruk untuk bekerja di sekitar batas ORM.

Saya telah melihat pendekatan sebelumnya bekerja dengan baik pada proyek J2EE yang sangat besar (100 tahun staf).

Dimana ORM mungkin bukan yang paling cocok

Dalam kasus lain, mungkin ada pendekatan yang lebih sesuai dengan aplikasi daripada ORM. Pola Arsitektur Aplikasi Perusahaan Fowler memiliki bagian tentang pola akses data yang melakukan pekerjaan yang cukup baik dalam membuat katalog berbagai pendekatan untuk ini. Beberapa contoh yang pernah saya lihat tentang situasi di mana ORM mungkin tidak dapat diterapkan adalah:

  • Pada aplikasi dengan basis kode warisan yang substansial dari prosedur tersimpan, Anda mungkin ingin menggunakan lapisan akses data yang berorientasi fungsional (jangan disamakan dengan bahasa fungsional) untuk membungkus sprocs incumbent. Ini menggunakan kembali lapisan akses data dan desain database yang sudah ada (dan karena itu diuji serta di-debug), yang sering kali mewakili upaya pengembangan dan pengujian yang cukup substansial, dan menghemat keharusan untuk memigrasi data ke model database baru. Ini sering merupakan cara yang cukup baik untuk membungkus lapisan Java di sekitar basis kode PL / SQL lama, atau menargetkan ulang aplikasi VB, Powerbuilder, atau Delphi klien kaya dengan antarmuka web.

  • Variasi adalah tempat Anda mewarisi model data yang belum tentu cocok dengan pemetaan ATAU. Jika (misalnya) Anda menulis antarmuka yang mengisi atau mengekstrak data dari antarmuka asing, Anda mungkin lebih baik bekerja langsung dengan database.

  • Aplikasi keuangan atau jenis sistem lain yang mengutamakan integritas data lintas sistem, terutama jika Anda menggunakan transaksi terdistribusi yang kompleks dengan commit dua fase. Anda mungkin perlu mengatur transaksi Anda secara mikro lebih baik daripada yang mampu didukung ORM.

  • Aplikasi berperforma tinggi di mana Anda ingin benar-benar menyesuaikan akses database Anda. Dalam kasus ini, mungkin lebih baik bekerja di tingkat yang lebih rendah.

  • Situasi di mana Anda menggunakan mekanisme akses data incumbent seperti ADO.Net itu 'cukup baik' dan bermain dengan baik dengan platform adalah manfaat yang lebih besar daripada yang diberikan ORM.

  • Kadang-kadang data hanyalah data - mungkin saja (misalnya) aplikasi Anda bekerja dengan 'transaksi' daripada 'objek' dan ini adalah tampilan domain yang masuk akal. Contohnya mungkin paket keuangan tempat Anda mendapatkan transaksi dengan bidang analisis yang dapat dikonfigurasi. Meskipun aplikasi itu sendiri dapat dibangun di atas platform OO, itu tidak terikat pada model domain bisnis tunggal dan mungkin tidak mengetahui lebih dari kode GL, akun, jenis dokumen, dan setengah lusin bidang analisis. Dalam hal ini aplikasi tidak mengetahui model domain bisnis seperti itu dan model objek (di luar struktur buku besar itu sendiri) tidak relevan dengan aplikasi.


"atau jenis sistem lain di mana integritas datanya penting" ... Selain situs web sosial, jika integritas data Anda tidak penting, mengapa repot-repot membangun sistem sama sekali?
ObiWanKenobi

3
Intinya secara khusus mengacu pada transaksi terdistribusi di mana beberapa sistem harus menjamin komit atau rollback secara sinkron atau keluar dari antrian pesan. Tidak semua sistem ini dibuat untuk Anda dan oleh karena itu belum tentu mendukung ORM. Anda mungkin harus mengelola transaksi secara eksplisit, yang mungkin mengharuskan Anda menggunakan level takelit yang lebih rendah daripada ORM.
ConcernedOfTunbridgeWells

1
Saya tahu ini sudah lebih dari setahun, tetapi +1 untuk Anda karena menyebutkan fakta bahwa terkadang data hanya sekadar itu, data.
luis.espinal

37

Pertama - menggunakan ORM tidak akan membuat kode Anda lebih mudah untuk diuji, juga tidak akan selalu memberikan keuntungan dalam scenerio Integrasi Berkelanjutan.

Dalam pengalaman saya, meskipun menggunakan ORM dapat meningkatkan kecepatan pengembangan, masalah terbesar yang perlu Anda tangani adalah:

  1. Menguji kode Anda
  2. Mempertahankan kode Anda

Solusi untuk ini adalah:

  1. Buat kode Anda dapat diuji (menggunakan prinsip SOLID )
  2. Tulis pengujian otomatis untuk kode sebanyak mungkin
  3. Jalankan pengujian otomatis sesering mungkin

Datang ke pertanyaan Anda, dua keberatan yang Anda sebutkan tampak lebih seperti ketidaktahuan daripada apa pun.

Tidak dapat menulis kueri SELECT dengan tangan (yang, menurut saya, itulah sebabnya salin-tempel diperlukan) tampaknya menunjukkan bahwa ada kebutuhan mendesak untuk beberapa pelatihan SQL.

Ada dua alasan mengapa saya tidak menggunakan ORM:

  1. Dilarang keras oleh kebijakan perusahaan (dalam hal ini saya akan bekerja di tempat lain)
  2. Proyek ini sangat intensif data dan menggunakan solusi khusus vendor (seperti BulkInsert) lebih masuk akal.

Penolakan yang biasa tentang ORM (khususnya NHibernate) adalah:

  1. Mempercepat

    Tidak ada alasan mengapa menggunakan ORM akan lebih lambat daripada Akses Data kode tangan. Faktanya, karena cache dan pengoptimalan yang ada di dalamnya, ini bisa lebih cepat. ORM yang baik akan menghasilkan sekumpulan kueri berulang yang dapat Anda optimalkan skema Anda. ORM yang baik juga akan memungkinkan pengambilan data terkait yang efisien menggunakan berbagai strategi pengambilan.

  2. Kompleksitas

    Berkenaan dengan kompleksitas, menggunakan ORM berarti lebih sedikit kode, yang umumnya berarti lebih sedikit kerumitan. Banyak orang yang menggunakan akses data tulisan tangan (atau yang dihasilkan kode) mendapati diri mereka menulis kerangka kerja mereka sendiri melalui pustaka akses data "tingkat rendah" (seperti menulis metode pembantu untuk ADO.Net). Ini sama dengan lebih banyak kerumitan, dan, lebih buruk lagi, mereka jarang didokumentasikan dengan baik, atau diuji dengan baik.
    Jika Anda melihat secara khusus di NHibernate, maka alat seperti Fluent NHibernate dan Linq To NHibernate juga memperlunak kurva pembelajaran.

Hal yang membuat saya tentang keseluruhan debat ORM adalah bahwa orang yang sama yang mengklaim bahwa menggunakan ORM akan terlalu keras / lambat / apa pun adalah orang yang sama yang lebih dari senang menggunakan Linq To Sql atau Dataset Diketik. Sementara Linq To Sql adalah langkah besar ke arah yang benar, masih beberapa tahun cahaya tertinggal di mana beberapa ORM open source berada. Namun, kerangka kerja untuk Dataset yang Diketik dan untuk Linq To Sql masih sangat kompleks, dan menggunakannya untuk melangkah terlalu jauh dari (Tabel = Kelas) + (CRUD dasar) sangatlah sulit.

Saran saya adalah jika, pada akhirnya, Anda tidak bisa mendapatkan ORM, pastikan akses data Anda terpisah dari kode lainnya, dan Anda mengikuti saran Gang Of Four tentang pengkodean untuk sebuah antarmuka. Juga, dapatkan kerangka Injeksi Ketergantungan untuk melakukan pemasangan kabel.

(Bagaimana dengan kata-kata kasar?)


33

Ada berbagai macam masalah umum di mana alat ORM seperti Hibernate adalah dewa-kirim, dan beberapa di mana itu merupakan penghalang. Saya tidak cukup tahu tentang proyek Anda untuk mengetahui yang mana.

Salah satu kelebihan Hibernate adalah Anda dapat mengatakan sesuatu hanya 3 kali: setiap properti disebutkan di kelas, file .hbm.xml, dan database. Dengan kueri SQL, properti Anda berada di kelas, database, pernyataan pilih, pernyataan sisipkan, pernyataan pembaruan, pernyataan hapus, dan semua kode marshalling dan unmarshalling yang mendukung kueri SQL Anda! Ini bisa menjadi cepat berantakan. Di sisi lain, Anda tahu cara kerjanya. Anda dapat men-debugnya. Tidak apa-apa ada di lapisan ketekunan Anda sendiri, tidak terkubur di bagian penting alat pihak ketiga.

Hibernate bisa menjadi poster-child untuk Spolsky's Law of Leaky Abstractions. Sedikit keluar jalur, dan Anda perlu mengetahui cara kerja internal alat yang mendalam. Ini bisa sangat menjengkelkan ketika Anda tahu Anda bisa memperbaiki SQL dalam beberapa menit, tetapi sebaliknya Anda menghabiskan berjam-jam mencoba membujuk alat dang Anda untuk menghasilkan SQL yang masuk akal. Debugging terkadang menjadi mimpi buruk, tetapi sulit untuk meyakinkan orang yang belum pernah ke sana.

EDIT: Anda mungkin ingin melihat ke iBatis.NET jika mereka tidak akan berbalik tentang NHibernate dan mereka ingin mengontrol kueri SQL mereka.

EDIT 2: Namun, inilah tanda bahaya besar: "Praktik yang baik, yang terlihat cukup normal di Stack Overflow, seperti pengujian unit atau integrasi berkelanjutan, tidak ada di sini hingga saat ini." Jadi, para developer "berpengalaman" ini, apa yang mereka alami dalam mengembangkannya? Keamanan pekerjaan mereka? Sepertinya Anda termasuk orang yang tidak terlalu tertarik pada bidang ini, jadi jangan biarkan mereka membunuh minat Anda. Anda harus menjadi keseimbangan. Lakukan perlawanan.


3
Pengulangan tidak benar lagi. Jika Anda menggunakan anotasi JPA, Anda hanya perlu menentukannya sekali. Hibernate bahkan akan membangun database Anda membuat pernyataan untuk Anda, meskipun itu paling berguna untuk menentukan apakah pemetaan Anda benar.
jonathan-stafford

Diskusi yang seimbang tentang masalah. Pengalaman kerangka kerja Entitas Saya sangat cocok dengan deskripsi Anda tentang "menghabiskan berjam-jam mencoba membujuk alat dang Anda", dan "sulit untuk meyakinkan orang yang belum pernah ke sana". Tampaknya lebih cepat untuk menulis, tetapi merupakan pemborosan waktu yang sangat besar untuk membuat kinerja yang sangat baik.

2
8 tahun telah berlalu, tetapi itu masih benar: "Ini bisa sangat menjengkelkan ketika Anda tahu Anda bisa memperbaiki SQL dalam beberapa menit, tetapi sebaliknya Anda menghabiskan berjam-jam mencoba membujuk alat dang Anda untuk menghasilkan SQL yang masuk akal."
Ruslan Stelmachenko

13

Saya mengerjakan satu proyek di mana tidak menggunakan ORM sangat berhasil. Itu adalah proyek itu

  1. Harus dilakukan secara horizontal dari awal
  2. Harus dikembangkan dengan cepat
  3. Memiliki model domain yang relatif sederhana

Waktu yang diperlukan untuk membuat NHibernate bekerja dalam struktur yang dipartisi secara horizontal akan jauh lebih lama daripada waktu yang dibutuhkan untuk mengembangkan pembuat data super sederhana yang menyadari skema partisi kami ...

Jadi, dalam 90% proyek yang telah saya kerjakan, ORM telah menjadi bantuan yang sangat berharga. Tetapi ada beberapa keadaan yang sangat spesifik di mana saya dapat melihat tidak menggunakan ORM sebagai yang terbaik.


Anda memberikan beberapa poin bagus untuk tidak menggunakan ORM dalam beberapa kasus tertentu. Namun, proyek ini termasuk dalam 90% di mana ORM mungkin dapat membantu mengurangi biaya pengembangan dan pemeliharaan.
hangy

Sangat setuju - maaf karena tidak menjawab pertanyaan Anda secara langsung! Saya percaya bahwa alasan spesifik yang Anda sebutkan cukup tidak valid :)
Mike


11

Izinkan saya mengatakan bahwa ORM dapat membuat kehidupan pengembangan Anda lebih mudah jika diintegrasikan dengan benar, tetapi ada beberapa masalah di mana ORM sebenarnya dapat mencegah Anda mencapai persyaratan dan tujuan yang Anda nyatakan.

Saya telah menemukan bahwa ketika merancang sistem yang memiliki persyaratan kinerja yang berat, saya sering tertantang untuk menemukan cara agar sistem lebih berkinerja. Sering kali, saya berakhir dengan solusi yang memiliki profil kinerja tulis yang berat (artinya kami menulis data lebih banyak daripada kami membaca data). Dalam kasus ini, saya ingin memanfaatkan fasilitas yang ditawarkan platform database kepada saya untuk mencapai tujuan kinerja kami (OLTP, bukan OLAP). Jadi jika saya menggunakan SQL Server dan saya tahu saya memiliki banyak data untuk ditulis, mengapa saya tidak menggunakan penyisipan massal ... yah, seperti yang mungkin telah Anda temukan, sebagian besar ORMS (saya tidak tahu apakah bahkan satu pun tidak) tidak memiliki kemampuan untuk memanfaatkan keunggulan khusus platform seperti penyisipan massal.

Anda harus tahu bahwa Anda dapat memadukan teknik ORM dan non-ORM. Saya baru saja menemukan bahwa ada beberapa kasus edge di mana ORM tidak dapat mendukung kebutuhan Anda dan Anda harus mengatasinya untuk kasus tersebut.


9

Saat Anda perlu memperbarui 50000000 catatan. Pasang bendera atau apapun.

Coba lakukan ini menggunakan ORM tanpa memanggil prosedur tersimpan atau perintah SQL asli ..

Pembaruan 1: Coba juga mengambil satu catatan dengan hanya beberapa bidangnya. (Jika Anda memiliki tabel yang sangat "lebar"). Atau hasil skalar. ORM juga payah.

PEMBARUAN 2 : Tampaknya EF 5.0 beta menjanjikan pembaruan batch tetapi ini adalah berita yang sangat panas (2012, Januari)



9

Untuk aplikasi perusahaan berbasis database non-sepele, sebenarnya tidak ada alasan untuk tidak menggunakan ORM.

Fitur samping:

  • Dengan tidak menggunakan ORM, Anda memecahkan masalah yang telah diselesaikan berulang kali oleh komunitas besar atau perusahaan dengan sumber daya yang signifikan.
  • Dengan menggunakan ORM, bagian inti dari lapisan akses data Anda mendapatkan manfaat dari upaya debug komunitas atau perusahaan tersebut.

Untuk meletakkan beberapa perspektif dalam argumen, pertimbangkan keuntungan menggunakan ADO.NET vs. menulis kode untuk mengurai aliran data tabel itu sendiri.

Saya telah melihat ketidaktahuan tentang bagaimana menggunakan ORM membenarkan penghinaan pengembang untuk ORMs Misalnya: eager loading (sesuatu yang saya perhatikan Anda tidak menyebutkan). Bayangkan Anda ingin mendapatkan kembali pelanggan dan semua pesanan mereka, dan untuk semua item detail pesanan tersebut. Jika Anda hanya mengandalkan pemuatan lambat, Anda akan meninggalkan pengalaman ORM dengan pendapat: "ORM lambat." Jika Anda mempelajari cara menggunakan eager loading, Anda akan melakukannya dalam 2 menit dengan 5 baris kode, apa yang perlu waktu setengah hari untuk diterapkan oleh rekan kerja Anda: satu kueri ke database dan mengikat hasilnya ke hierarki objek. Contoh lain adalah kesulitan menulis kueri SQL secara manual untuk mengimplementasikan paging.

Pengecualian yang mungkin untuk menggunakan ORM adalah jika aplikasi itu adalah kerangka kerja ORM yang dirancang untuk menerapkan abstraksi logika bisnis khusus, dan dirancang untuk digunakan kembali pada beberapa proyek. Meskipun demikian, Anda akan mendapatkan adopsi yang lebih cepat dengan meningkatkan ORM yang ada dengan abstraksi tersebut.

Jangan biarkan pengalaman anggota tim senior menyeret Anda ke arah berlawanan dari evolusi ilmu komputer. Saya telah berkembang secara profesional selama 23 tahun, dan salah satu konstanta adalah penghinaan terhadap yang baru oleh sekolah lama. ORM adalah SQL sebagai bahasa C untuk perakitan, dan Anda dapat bertaruh bahwa setara dengan C ++ dan C # sedang dalam perjalanan. Satu baris kode sekolah baru sama dengan 20 baris kode sekolah lama.


8

Saya pikir mungkin ketika Anda bekerja pada sistem yang lebih besar Anda dapat menggunakan alat pembuat kode seperti CodeSmith daripada ORM ... Saya baru-baru ini menemukan ini: Cooperator Framework yang menghasilkan Prosedur Tersimpan SQL Server dan juga menghasilkan entitas bisnis, pembuat peta, gateway, lazyload dan semua itu di C # ... lihatlah ... itu ditulis oleh tim di sini di Argentina ...

Saya pikir itu di tengah-tengah antara pengkodean seluruh lapisan akses data dan menggunakan ORM ...


6

Secara pribadi, saya telah (sampai saat ini) menentang untuk menggunakan ORM, dan digunakan untuk bertahan dengan menulis lapisan akses data yang merangkum semua perintah SQL. Keberatan utama ORM adalah bahwa saya tidak mempercayai implementasi ORM untuk menulis SQL yang tepat. Dan, dilihat dari ORM yang biasa saya lihat (kebanyakan perpustakaan PHP), saya pikir saya sepenuhnya benar.

Sekarang, sebagian besar pengembangan web saya menggunakan Django, dan saya menemukan ORM yang disertakan benar-benar nyaman, dan karena model data diekspresikan pertama kali dalam istilah mereka, dan baru kemudian dalam SQL, ia bekerja dengan sempurna untuk kebutuhan saya. Saya yakin tidak akan terlalu sulit untuk berkembang dan perlu melengkapi dengan SQL yang ditulis tangan; tapi untuk akses CRUD sudah lebih dari cukup.

Saya tidak tahu tentang NHibernate; tapi saya rasa itu juga "cukup baik" untuk sebagian besar dari apa yang Anda butuhkan. Tetapi jika pembuat kode lain tidak mempercayainya; itu akan menjadi tersangka utama pada setiap bug yang berhubungan dengan data, membuat verifikasi menjadi lebih membosankan.

Anda dapat mencoba memperkenalkannya secara bertahap di tempat kerja Anda, pertama-tama fokuslah pada aplikasi kecil yang 'jelas', seperti akses data sederhana. Setelah beberapa saat, itu mungkin digunakan pada prototipe, dan mungkin tidak diganti ...


5

Jika ini adalah database OLAP (misalnya, data statis, hanya-baca yang digunakan untuk pelaporan / analitik, dll.), Maka penerapan kerangka kerja ORM tidak sesuai. Sebaliknya, lebih disukai menggunakan fungsionalitas akses data asli database seperti prosedur yang tersimpan. ORM lebih cocok untuk sistem transaksional (OLTP).


Apa kamu yakin akan hal itu? OLTP sama tidak cocoknya dengan ORM seperti OLAP (maksud saya, tergantung pada kerumitannya). Ada berbagai macam aplikasi di antara dua ekstrem ini di mana ORM melakukan pekerjaan dengan baik. Tapi untuk OLAP dan OLTP, mereka bisa menjadi penghalang.
luis.espinal

4

Saya rasa ada banyak alasan bagus untuk tidak menggunakan ORM. Pertama dan terpenting, saya adalah pengembang .NET dan saya ingin tetap berpegang pada apa yang telah diberikan kerangka .NET yang luar biasa kepada saya. Itu melakukan semua yang mungkin saya butuhkan. Dengan melakukan ini, Anda tetap menggunakan pendekatan yang lebih standar, dan dengan demikian ada peluang yang jauh lebih baik dari pengembang lain yang mengerjakan proyek yang sama di kemudian hari untuk dapat mengambil apa yang ada dan menjalankannya. Kemampuan akses data yang sudah disediakan oleh Microsoft cukup luas, tidak ada alasan untuk membuangnya.

Saya telah menjadi pengembang profesional selama 10 tahun, memimpin banyak proyek jutaan + dolar yang sangat sukses, dan saya tidak pernah menulis aplikasi yang diperlukan untuk dapat beralih ke database apa pun. Mengapa Anda ingin klien melakukan ini? Rencanakan dengan hati-hati, pilih database yang tepat untuk apa yang Anda butuhkan, dan pertahankan. Secara pribadi SQL Server telah mampu melakukan apa pun yang perlu saya lakukan. Mudah dan berfungsi dengan baik. Bahkan ada versi gratis yang mendukung data hingga 10GB. Oh, dan itu bekerja luar biasa dengan .NET.

Saya baru-baru ini harus mulai mengerjakan beberapa proyek yang menggunakan ORM sebagai datalayer. Saya pikir itu buruk, dan sesuatu yang ekstra saya harus belajar bagaimana menggunakan tanpa alasan apapun. Dalam keadaan yang sangat jarang terjadi, pelanggan memang perlu mengubah database, saya dapat dengan mudah mengerjakan ulang seluruh datalayer dalam waktu yang lebih singkat daripada yang saya habiskan untuk menipu penyedia ORM.

Sejujurnya saya pikir ada satu kegunaan nyata untuk ORM: Jika Anda membangun aplikasi seperti SAP yang benar-benar membutuhkan kemampuan untuk berjalan di banyak database. Jika tidak sebagai penyedia solusi, saya memberi tahu klien saya bahwa aplikasi ini dirancang untuk berjalan di database ini dan begitulah adanya. Sekali lagi, setelah 10 tahun dan aplikasi yang tak terhitung jumlahnya, ini tidak pernah menjadi masalah.

Jika tidak, menurut saya ORM adalah untuk pengembang yang tidak terlalu memahami, dan menurut saya, semakin keren alat pihak ketiga yang mereka gunakan dalam aplikasi, semakin baik aplikasi mereka. Saya akan menyerahkan hal-hal seperti ini kepada para penggemar berat uber sementara saya mengeluarkan perangkat lunak yang jauh lebih hebat sementara itu pengembang mana pun dapat mengambil dan segera menjadi produktif.


2
Saya benar-benar tidak mengerti mengapa jawaban ini ditolak. Menjaga kesederhanaan dengan menggunakan apa pun yang ditawarkan lingkungan Anda adalah praktik yang bagus. Sebagai ahli kode bersih yang berpengalaman, saya menemukan bahwa orm sulit dibaca, dan karenanya sulit dipelihara. Anda tidak tahu kueri apa yang dieksekusi dengan tepat ketika Anda memiliki hubungan kompleks dalam aplikasi Anda (yang pada akhirnya akan Anda lakukan). Menjadi tidak mungkin untuk men-debug kekacauan seperti itu dalam jangka panjang. Saya katakan, tetap sederhana, jangan gunakan ORM.
David

Ini lucu. Saya telah menjadi pengembang selama 24 tahun dan saya tidak pernah terlibat dalam proyek yang hanya memungkinkan untuk mendukung satu vendor RDBMS. Setiap proyek MEMBUTUHKAN kami untuk mendukung beberapa vendor RDBMS, karena kami harus cukup fleksibel untuk bekerja dengan pelanggan yang MEMERLUKAN Oracle, dan bekerja dengan pelanggan lain yang MEMERLUKAN SQL Server. Jika Anda membuat aplikasi pipa tungku di ruang hampa, maka Anda bisa mendiktekan RDBMS saja. Tapi saya tidak pernah terlibat dalam proyek yang bisa diterima.
deltamind106

Saya memiliki banyak aplikasi di mana saya dapat mendikte RDBMS terutama karena pada sejumlah aplikasi internal dan pelanggan yang melihat data "kami". Saya telah menjadi pengembang selama 24 tahun juga.
jeffkenn

3

Performa runtime adalah satu-satunya downside nyata yang dapat saya pikirkan tetapi saya pikir itu lebih dari pertukaran yang adil untuk waktu ORM menyelamatkan Anda dari pengembangan / pengujian / dll. Dan dalam banyak kasus, Anda harus dapat menemukan kemacetan data dan mengubah struktur objek Anda menjadi lebih efisien.

Saya belum pernah menggunakan Hibernate sebelumnya tetapi satu hal yang saya perhatikan dengan beberapa solusi ORM "off-the-shelf" adalah kurangnya fleksibilitas. Saya yakin ini tergantung pada mana Anda pergi dan apa yang perlu Anda lakukan dengannya.


Saya ingat beberapa orang mengatakan bahwa kueri yang dioptimalkan dan tidak memuat data tidak diperlukan dalam beberapa situasi (mis. Pemuatan gabungan yang lambat) sebenarnya dapat mempercepat sesuatu. Menerapkan ini secara manual dalam DAL khusus mungkin lebih berhasil dan menghemat waktu.
hangy

3

Ada dua aspek ORM yang mengkhawatirkan. Pertama, mereka adalah kode yang ditulis oleh orang lain, terkadang sumber tertutup, terkadang sumber terbuka tetapi cakupannya sangat besar. Kedua, mereka menyalin data.

Masalah pertama menyebabkan dua masalah. Anda mengandalkan kode orang luar. Kita semua melakukan ini, tetapi pilihan untuk melakukannya tidak boleh dianggap enteng. Dan bagaimana jika itu tidak melakukan apa yang Anda butuhkan? Kapan Anda akan menemukan ini? Anda tinggal di dalam kotak yang digambar ORM untuk Anda.

Masalah kedua adalah salah satu dari dua fase komit. Database relasional sedang disalin ke model objek. Anda mengubah model objek dan itu seharusnya memperbarui database. Ini adalah komit dua fase dan bukan hal termudah untuk di-debug.


2
Umm ... jika Anda menggunakan, katakanlah .NET, Anda mengandalkan kode mereka (yang tidak dapat Anda modifikasi). Saya tidak melihat bagaimana itu lebih "baik" daripada mengandalkan kode NHibernate, misalnya. Menjadi paranoid perpustakaan yang belum Anda tulis sendiri relatif konyol. Kedengarannya Anda menderita NIH
Jason Bunting

compiler dan VM adalah bagian CS yang relatif stabil, dan tidak terlalu sulit untuk melakukan pengujian. desain ORM memiliki banyak cara untuk menjadi 'sedikit salah', atau dokumentasi yang tidak lengkap. semua ini membuatnya lebih sulit dipercaya daripada sesuatu yang begitu mendasar seperti kompilator.
Javier

1
Ini adalah peringatan ... bukan pernyataan jangan gunakan. Dan itu hanya satu peringatan dari tiga masalah.
dacracot

1
@dacracot: Anda mengandalkan banyak kode asing sepanjang waktu ... mulai dari sistem operasi Anda, jadi menurut saya maksud Anda tidak valid. Poin kedua dapat dimitigasi dengan menggunakan penguncian optimis, terlebih lagi tidak ada hubungannya dengan komit dua fase.
Adam Byrtek

1
dacracot tepat ketika berbicara tentang beberapa ORM yang kurang matang. Saya yakin ada beberapa yang sangat hebat, tetapi sebagian besar tidak akan sempurna, dan ini bisa menjadi masalah di beberapa (tidak sebagian besar) lingkungan. Mengenai komit dua fase ... ada cara untuk membuat model transaksi DB itu sendiri dalam kode, tetapi mengapa menambahkan lapisan tipuan yang tidak memberikan abstraksi apa pun?
Tom


3

Pengalaman yang saya alami dengan Hibernate adalah semantiknya halus, dan ketika ada masalah, agak sulit untuk memahami apa yang salah. Saya pernah mendengar dari seorang teman bahwa sering kali seseorang memulai dengan Kriteria, kemudian membutuhkan sedikit lebih banyak fleksibilitas dan membutuhkan HQL, dan kemudian pemberitahuan bahwa bagaimanapun, SQL mentah diperlukan (misalnya, Hibernate tidak memiliki AFAIK gabungan).

Juga dengan ORM, orang dengan mudah cenderung terlalu sering menggunakan pemetaan / model yang ada, yang mengarah pada adanya objek dengan banyak atribut yang tidak diinitilisasi. Jadi setelah kueri, di dalam transaksi Hibernate membuat pengambilan data tambahan, yang menyebabkan potensi perlambatan. Sayangnya, objek model hibernasi terkadang bocor ke lapisan arsitektur tampilan, lalu kita melihat LazyInitializationExceptions.

Untuk menggunakan ORM, seseorang harus benar-benar memahaminya. Sayangnya orang mudah mendapat kesan bahwa itu mudah padahal tidak.


Hibernate tidak mendukung UNION? Itu adalah bagian yang cukup mendasar dari teori himpunan! Saya kira itu hanya menunjukkan cara berbeda untuk memikirkan masalah.
Tom

3

Bukan untuk menjadi jawaban semata, saya ingin mengulang kutipan yang saya dengar baru-baru ini. "ORM yang baik itu seperti Yeti, semua orang membicarakannya tetapi tidak ada yang melihatnya."

Setiap kali saya menggunakan ORM, saya biasanya menemukan diri saya berjuang dengan masalah / keterbatasan ORM itu. Pada akhirnya, ya itu melakukan apa yang saya inginkan dan itu ditulis di suatu tempat dalam dokumentasi yang buruk itu tetapi saya mendapati diri saya kehilangan satu jam lagi yang tidak akan pernah saya dapatkan. Siapapun yang menggunakan nhibernate, kemudian nhibernate dengan lancar di postgresql akan mengerti apa yang telah saya alami. Perasaan konstan "kode ini tidak di bawah kendali saya" benar-benar menyebalkan.

Saya tidak menuding atau mengatakan itu buruk, tetapi saya mulai memikirkan apa yang saya berikan hanya untuk mengotomatiskan CRUD dalam satu ekspresi. Saat ini saya pikir saya harus menggunakan ORM lebih sedikit, mungkin membuat atau menemukan solusi yang memungkinkan operasi db minimal. Tapi itu hanya aku. Saya percaya ada beberapa hal yang salah di arena ORM ini tetapi saya tidak cukup terampil untuk mengungkapkannya.


Bertahun-tahun (dan ORM) kemudian saya memutuskan untuk menggunakan Postgresql / EntityFramework dengan Migrasi Pertama Kode. Ini memungkinkan saya mengaktifkan persistensi data melalui kelas yang saya tulis dan akhirnya saya dapat menyinkronkan / membuat versi perubahan database saya yang terintegrasi ke lingkungan produksi saya. Ini hampir merupakan lapisan akses data yang transparan, dan menghemat banyak waktu selama pengembangan, tetapi sementara itu saya dapat mendalami dan menulis kueri tingkat lanjut kapan pun saya mau. Tentu saja, ini adalah solusi dotnet tetapi saya akhirnya merasa damai dengan akses db.
detay

2

Saya pikir menggunakan ORM masih merupakan ide yang bagus. Terutama mengingat situasi yang Anda berikan. Kedengarannya dengan posting Anda Anda lebih berpengalaman dalam hal strategi akses db, dan saya akan membahas menggunakan ORM.

Tidak ada argumen untuk # 1 karena menyalin dan menempel kueri dan pengkodean keras dalam teks tidak memberikan fleksibilitas, dan untuk # 2 kebanyakan orm akan membungkus pengecualian asli, akan memungkinkan pelacakan kueri yang dihasilkan, dll, jadi debugging juga bukan ilmu roket.

Sedangkan untuk validasi, menggunakan ORM biasanya juga akan memberikan waktu yang lebih mudah untuk mengembangkan strategi validasi, di atas validasi bawaan apa pun.

Menulis kerangka kerja Anda sendiri bisa melelahkan, dan sering kali ada yang terlewat.

EDIT: Saya ingin membuat satu hal lagi. Jika perusahaan Anda mengadopsi strategi ORM, yang semakin meningkatkan nilainya, karena Anda akan mengembangkan pedoman dan praktik untuk menggunakan dan menerapkan dan setiap orang akan semakin meningkatkan pengetahuan mereka tentang kerangka kerja yang dipilih, mengurangi salah satu masalah yang Anda angkat. Juga, Anda akan belajar apa yang berhasil dan apa yang tidak ketika situasi muncul, dan pada akhirnya akan menghemat banyak waktu dan tenaga.


1

Setiap ORM, bahkan yang "bagus", dibebani dengan sejumlah asumsi tertentu yang terkait dengan mekanisme dasar yang digunakan perangkat lunak untuk meneruskan data bolak-balik antara lapisan aplikasi dan penyimpanan data Anda.

Saya telah menemukan bahwa untuk aplikasi yang cukup canggih, bahwa mengerjakan asumsi tersebut biasanya membutuhkan lebih banyak waktu daripada sekadar menulis solusi yang lebih langsung seperti: kueri data, dan secara manual membuat instance entitas baru.

Secara khusus, Anda kemungkinan besar akan mengalami hambatan segera setelah Anda menggunakan kunci multi-kolom atau hubungan yang cukup kompleks yang berada tepat di luar cakupan contoh praktis yang diberikan ORM Anda saat Anda mendownload kode.

Saya mengakui bahwa untuk jenis aplikasi tertentu, terutama yang memiliki jumlah tabel database yang sangat besar, atau tabel database yang dihasilkan secara dinamis, bahwa proses sihir otomatis dari ORM dapat berguna.

Jika tidak, persetan dengan ORM. Sekarang saya menganggap mereka pada dasarnya hanya iseng.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.