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

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.)

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.

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.

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.

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?)

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.

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.

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.

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)

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.

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 ...

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 ...

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).

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.

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.

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.

Saya menyarankan bacaan ini untuk daftar kelemahan ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Bagi saya sendiri, saya menemukan ORM sangat berguna untuk sebagian besar aplikasi yang saya tulis!

/ Asger

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.

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.

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.

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.