Apa kriteria untuk mengevaluasi ORM untuk. NET? [Tutup]


30

Saya melihat evaluasi ORM.

Saya telah menggunakan SubSonic , Linq-to-SQL dan Entity Framework . Saya memiliki tim pengembang mulai dari junior hingga senior.

Apa kriteria untuk mengevaluasi ORM untuk. NET?


8
Tidak ada yang terbaik. Ada banyak opsi yang memiliki serangkaian pro dan kontra. Masing-masing membawa sesuatu yang berbeda ke meja.
Tony

Satu pendapat tentang terminologi: Saya akan mengatakan SubSonic pasti bukan ORM. Lebih dari .. pemaparan relasional-ke-objek. Itu hanya dapat menghasilkan kelas yang secara langsung mencerminkan skema tabel database Anda. Ini berfungsi baik untuk sebagian besar, tetapi titik desain ini cukup penting karena berada di lapangan bermain yang sangat berbeda dari EF & NHib.
quentin-starin

1
@qstarin: yang menjadikan SubSonic ORM sebanyak LINQ-to-SQL.
John Saunders

Poin yang sangat bagus, John dan qstarin. ini adalah garis tipis yang Anda kategorikan sebagai ekspositor relasional-ke-objek. SubSonic 3.0 menawarkan fitur yang sejalan dengan konsep ORM. Kata Wiki. "Mengkonversi data antara sistem tipe yang tidak kompatibel dalam bahasa pemrograman berorientasi objek. Ini pada dasarnya menciptakan" database objek virtual "yang dapat digunakan dari dalam bahasa pemrograman." selanjutnya di ormbattle.net SubSonic dianggap sebagai ORM. Terima kasih atas tanggapan Anda
Nickz

2
Saya melihat Linq-to-SQL lebih seperti generator sql yang dimuliakan daripada ORM ...
fretje

Jawaban:


43

Itu pertanyaan yang sarat.
Ada banyak ORM yang sangat baik mendekati subjek dengan filosofi yang berbeda.
Tidak ada yang sempurna dan semua cenderung menjadi kompleks segera setelah Anda menyimpang dari jalur emas mereka (dan kadang-kadang bahkan ketika Anda berpegang teguh pada itu).

Apa yang harus Anda tanyakan pada diri sendiri ketika memilih ORM:

  1. Apa yang perlu dilakukan untuk Anda?
    Jika Anda sudah memiliki seperangkat persyaratan untuk aplikasi Anda, maka Anda harus memilih ORM yang lebih cocok dengan ini daripada hipotesis 'terbaik'.

  2. Apakah data Anda dibagikan atau hanya lokal?
    Banyak hairiness dalam ORM disebabkan oleh bagaimana mereka menangani konkurensi dan perubahan data dalam database ketika banyak pengguna memegang versi dari data yang sama.
    Jika datastore Anda hanya untuk satu pengguna, maka sebagian besar ORM akan melakukan pekerjaan dengan baik. Namun, tanyakan pada diri sendiri beberapa pertanyaan sulit dalam skenario multi-pengguna: bagaimana cara penguncian ditangani? Apa yang terjadi ketika saya menghapus objek? Bagaimana pengaruhnya terhadap objek terkait lainnya? Apakah ORM bekerja dekat dengan logam backend atau apakah itu menyimpan banyak data (meningkatkan kinerja dengan mengorbankan peningkatan risiko staleness).

  3. Apakah ORM disesuaikan dengan baik untuk jenis aplikasi Anda? ORM tertentu mungkin sulit untuk dikerjakan (banyak overhead kinerja, sulit dikodekan) jika digunakan dalam layanan atau duduk di dalam aplikasi web. Sebaliknya mungkin bagus untuk aplikasi desktop.

  4. Apakah Anda harus melepaskan perangkat tambahan khusus basis data?
    ORM cenderung menggunakan seperangkat SQL common denominator terendah untuk memastikan mereka bekerja dengan banyak backend database yang berbeda.
    Semua ORM akan berkompromi pada fitur yang tersedia (kecuali jika mereka secara khusus menargetkan backend tunggal) tetapi beberapa akan memungkinkan Anda untuk menerapkan perilaku tambahan untuk mengeksploitasi peningkatan spesifik yang tersedia di backend yang Anda pilih.
    Perangkat tambahan khusus-db adalah kemampuan pencarian Teks Lengkap misalnya; pastikan ORM Anda memberi Anda cara untuk mengakses fitur-fitur ini jika Anda membutuhkannya.

  5. Bagaimana ORM mengelola perubahan dalam model data?
    Beberapa dapat memperbarui DB secara otomatis dalam ukuran tertentu, yang lain tidak melakukan apa-apa dan Anda harus melakukan pekerjaan kotor sendiri; lainnya menyediakan kerangka kerja untuk menangani perubahan yang memungkinkan Anda mengontrol pembaruan basis data.

  6. Apakah Anda ingin memasangkan aplikasi Anda ke objek ORM atau Anda lebih suka menangani POCO dan menggunakan adaptor untuk kegigihan?
    Yang pertama biasanya mudah ditangani tetapi membuat dependensi pada objek data ORM khusus Anda di mana-mana, yang terakhir lebih fleksibel, dengan biaya sedikit lebih banyak kode.

  7. Apakah Anda perlu memindahkan objek Anda dari jarak jauh?
    Tidak semua ORM sama dalam hal mengambil objek dari server jauh, perhatikan dengan cermat apa yang mungkin atau tidak mungkin dilakukan. Beberapa efisien, yang lain tidak.

  8. Apakah ada seseorang yang bisa Anda hubungi?
    Apakah ada dukungan komersial yang baik? Seberapa besar dan aktif komunitas di sekitar proyek?
    Apa masalah pengguna yang ada dengan produk?
    Apakah mereka mendapatkan solusi cepat?

Beberapa ORM yang saya lihat:

  • XPO
    Dari developer Express: kecil dan sederhana, kode-sentris. Mereka menggunakannya untuk kerangka aplikasi mereka eXpressApp .
  • NHibernate
    Gratis, tetapi kurva belajarnya agak curam. Banyak barang tetapi sulit untuk menemukan apa yang benar-benar relevan kadang-kadang di semua dokumentasi yang terpecah-pecah.
  • LLBLGen Pro
    proyek yang sangat matang, bukan yang paling sederhana tetapi banyak pemikiran telah dimasukkan ke dalamnya.
  • Kerangka Entitas
    GEtting di sana. Rilis terakhir cukup bagus dan MS mendengarkan, meskipun masih sedikit muda dibandingkan dengan ORM lain yang lebih dewasa.
  • DataObject.Net
    Terlihat menjanjikan tetapi juga agak baru untuk mengambil risiko proyek penting di atasnya IMHO. Cukup aktif sekalipun.

Ada banyak yang lain tentu saja.

Anda dapat melihat situs kontroversial ORM Battle yang mencantumkan beberapa tolok ukur kinerja, meskipun Anda harus menyadari bahwa kecepatan mentah belum tentu merupakan faktor paling penting untuk proyek Anda dan bahwa produsen situs web adalah DataObject.Net.


3
Mengetahui hal itu, apa yang Anda pilih?
Steven Evers

terima kasih Renaud Bompuis, saya belum pernah mendengar tentang beberapa ORM yang terdaftar. Informasi yang Anda berikan adalah makanan yang enak untuk dipikirkan, terima kasih.
Nickz

1
@SnOrfus: masih menggunakan XPO tapi saya akan bermigrasi ke LLBLGen, itu solid, matang dan Anda tetap memegang kendali (jadi Anda masih bisa mendapatkan tangan Anda kotor jika Anda perlu / ingin) dan memungkinkan pemisahan masalah yang lebih memadai dan objek digunakan kembali (melalui Adaptor).
Renaud Bompuis

3
Patut dicatat bahwa Entity Framework sekarang pada versi 4.1 dan tentunya sekarang layak untuk dilihat.
Sean Kearon

Saya suka Stored Procs di server dan LINQ di klien. Cobalah untuk memilih ini! Tidak ada kurva belajar, tidak ada kejutan, tidak ada versi, tidak ada kejutan!
NoChance

14

Saya menggunakan NHibernate dan merasa cukup bagus.

Dalam kasus saya, ditautkan ke database MS Sql, tetapi Anda dapat terhubung ke database lain.

Tidak perlu waktu lama untuk bangun dan berjalan - cukup peta objek Anda ke model - Saya menggunakan file xml tetapi Anda dapat melakukannya dengan lancar dalam kode. Ada komunitas yang hebat, dan secara pribadi saya menemukan pekerjaan Ayende sangat membantu - Saya menggunakan NHProf yang merupakan alat profil sql.

Saya kebanyakan menggunakan fungsi di luar kotak - pemetaan objek lurus, tetapi saya juga menggunakan Bahasa Qubernate Hibernate, yang cukup mudah untuk dipahami.


Hati-hati, NHibernate bisa rumit untuk model yang lebih rumit. Semuanya didokumentasikan dengan baik dan sangat masuk akal, tetapi jika Anda tidak sadar Anda dapat mengalami masalah. Artinya, kurva belajarnya tinggi, tetapi sangat bagus.
Matt Olenik

terima kasih Sam, saya belum menggunakan nhibernate namun tampaknya memerlukan konfigurasi yang luas dibandingkan dengan SubSonic, Linq-to-SQL dan Entity Framework. Ini tidak ideal untuk tim pengembangan saya.
Nickz

Jika Anda tertarik, Ayende memberikan lokakarya NHibernate di konferensi YOW Australia - yowconference.com.au/melbourne/events_tracks/… - pada bulan November / Desember. Salah satu orang yang bekerja dengan saya menggunakannya untuk sementara waktu, jadi saya mendapat manfaat dari belajar darinya.
Sam J

3
@Nick, sebagian besar konfigurasi dapat otomatis. Saya juga akan memeriksa add fasih.
stonemetal

@Nick, @stonemetal setuju, Fluent NHibernate membuat segalanya lebih mudah. Ini tidak secepat SubSonic, tetapi masih layak untuk dilihat.
Matt Olenik

6

Sayangnya, dalam tiga pekerjaan terakhir saya, kami memiliki tiga ORM rumahan. Dalam setiap kasus, mereka kebanyakan mengisap karena berbagai alasan.

Saya baru-baru ini mengevaluasi Entity Framework 4 dan dukungan POCO-nya (langkah-langkah bagus ada di sini ) dan saya benar-benar terkesan dengan betapa bagusnya itu tetap keluar dari wajah saya dan membuat saya merasa seperti sedang pemrograman lagi daripada menggiring data.


Saya dengar, jesse, pekerjaan sebelumnya saya berada di posisi yang sama dengan ORM rumahan. terima kasih atas umpan baliknya.
Nickz

3
ORM rumahan selalu payah. Yang terbaik selalu lebih buruk daripada ORM publik yang paling jelek.
Jaco Pretorius

@JacoPretorius Ada contoh tandingan untuk itu ... tapi "sebagai aturan umum" ...
pst


3

Saya suka Linq untuk Sql banyak. Sederhana dan memiliki desainer yang layak. Namun, saya berharap untuk mengakhiri kehidupan demi kerangka kerja Entity. Saya ingin dapat memanfaatkan kemampuan untuk memodifikasi generator sehingga saya dapat memiliki objek yang disesuaikan.

Manfaat terbesar yang dimiliki orang-orang ini dibandingkan orang lain (menurut saya) adalah mereka tidak cocok dengan VS. Ini juga negatif karena Anda berada di tangan MS (lihat Linq ke Sql).


3

[PENOLAKAN: Saya bekerja untuk DevExpress]

Anda dapat melihat tangkapan layar dari aplikasi-aplikasi biasa yang dibuat oleh kerangka kerja aplikasi DevExpress di sini . Halaman ini juga berisi ulasan singkat tentang produk kami. Untuk informasi lebih lanjut tentang alasannya , saya sarankan Anda memeriksa halaman produk masing-masing di situs web kami.

Sedangkan untuk DevExpress XAF dan XPO, berikut adalah penjelasan yang bagus tentang mengapa memilih kerangka kerja aplikasi kami. Plus, kami menyediakan dukungan dan dokumentasi, yang juga penting dan layak disebutkan. Jangan ragu untuk menghubungi kami jika ada pertanyaan.


Saya masih menggunakan XPO dan saya senang dengan pembaruan yang akan datang.
Renaud Bompuis

2

Kami menggunakan NHibernate + Fluent NHibernate, dengan Linq-to-Sql pada proyek-proyek kecil. Alasan untuk ini adalah:

1) (Bukan alasan utama) NHibernate tampaknya memiliki faktor "rasa hormat" yang lebih tinggi di antara para pengembang (apakah ini benar?),

2) Dibandingkan dengan linq-to-SQL, nHibernate memungkinkan pemetaan ORM antara objek dan entitas Db yang tidak memetakan 1-ke-1,

3) Kami belum secara ekstensif membandingkan nHibernate dengan Entity Framework 4.0 tetapi ini perbandingan yang bagus: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate memang memiliki sedikit kurva pembelajaran yang curam dan peta XML-nya bisa sangat bertele-tele, tetapi mulailah dengan dokumentasi situs Fluent Nhibernate dan lakukan cara Anda mundur.


1

Tidak ada kerangka kerja ORM "terbaik" karena mereka semua memiliki kombinasi kekuatan dan kelemahan yang berbeda dan cenderung menjadi kasus bahwa jika pengembang memilih untuk fokus membuat satu area lebih baik, ada area lain yang menderita dalam perbandingan (kode pertama vs model pertama vs basis data pertama).

Di sisi lain, ada beberapa yang sangat bagus yang beberapa di antaranya akan lebih cocok dengan keadaan dan filosofi pribadi Anda daripada yang lain.


Sunting: Untuk apa nilainya, saya saat ini menggunakan Linq to SQL - sebagian besar karena itu ada di sana meskipun sebagian karena ia melakukan banyak hal untuk usaha minimal dan mungkin akan berkembang ke Entity Framework lagi "karena itu ada" (meskipun demikian juga ada banyak tentang EF4 yang benar dan juga beberapa hal yang salah). Perhatian, terutama dengan yang terakhir, harus kinerja tetapi untuk sebagian besar kasus saya itu bukan masalah besar dan kemampuan untuk menjalankan Data Dinamis dan OData dari model (L2S dan EF) memiliki manfaat yang cukup besar bagi saya dalam hal " murah "menang.


Terima kasih atas tanggapan Anda, Murph. Saya menyetujui ORM "terbaik". Namun saya melihat untuk melembagakan standardisasi yang lebih banyak. Menggunakan salah satu ORM, akan membantu pengembang baru dan pengembang yang ada di tim saya. Saat ini di mana menggunakan semuanya, subsonik, ADO.net, linq-to-sql dan lain-lain bergerak antara proyek dan pemeliharaan menjadi lebih sulit.
Nickz

Oh, saya tidak punya masalah dengan pencarian Anda untuk ORM yang paling cocok untuk kasus penggunaan Anda dan saya sepenuhnya setuju dengan keinginan mengajukan pertanyaan di sini. Saya hanya melakukan kampanye yang sia-sia terhadap penggunaan kata "TERBAIK" dalam pertanyaan stackexchange (-:
Murph

1

Saya akan menyarankan Anda untuk melihat pada DevExpress XPO . Ini bersama dengan DevExpress XAF akan membuat hidup setiap pengembang mudah setelah kurva belajarnya dilewati.


XAF didasarkan pada XPO yang merupakan ORM. XAF sendiri membangun ini dan menambahkan logika dan "otomatis" UI dll.
Sascha

Tolong jelaskan mengapa Anda percaya DevExpress XAF akan membuat kehidupan seorang pengembang menjadi mudah.

@ Sascha, terima kasih atas petunjuk Anda. Saya telah memperbaiki posting saya.
Yogi Yang 007

@Mark, XAF bersama dengan XPO berfungsi sebagai ORM serta generator UI sehingga menjadi mudah bagi pengembang untuk membangun aplikasi fungsional penuh dalam .NET dengan kode minimum.
Yogi Yang 007

Satu komentar dari pihak saya untuk XAF: Ini adalah sistem yang bagus untuk lingkungan logika bisnis yang kompleks menengah karena mempercepat waktu pengembangan bagi mereka dalam faktor. Kelemahannya adalah, bahwa, pada batas tertentu, sekali lagi sangat memakan waktu untuk memperpanjangnya. Misalnya, pengguna hierarkis (bersama dengan tim yang menyukai logika) dan 'pengguna hanya dapat melihat item dirinya dan / atau bawahannya' tidak didukung di luar kotak. Jadi, XAF memiliki pro dan kontra itu benar-benar perlu dievaluasi apakah itu pas untuk proyek - IMHO. Tapi itu pasti fondasi yang dilakukan dengan baik jika cocok.
Sascha

1

Kami beruntung dengan Entity Framework. Namun, situasi kami agak tidak biasa - kami melakukan pengumpulan data untuk tim pelapor, sehingga mereka benar-benar merancang basis data. Kami mendapatkan DB dan kemudian hanya menggunakan EF untuk menghasilkan kelas akses data dari itu. Berfungsi bagus untuk kami, tetapi kami hanya melakukan banyak data massal, jadi saya tidak dapat menjamin seberapa baik kerjanya di lingkungan yang lebih transaksional.


2
Ya saya penggemar EF 4 yang jauh lebih baik daripada versi sebelumnya.
Nickz

1

NHibernate (+ FluentNHibernate) akan menjadi opsi default untuk saya. Ini sangat fleksibel, dapat dikembangkan, dan kuat. Ia memiliki sejumlah besar pengguna dan dipelihara dengan sangat aktif. Kelemahannya adalah kurva belajar yang curam.

LightSeed dari MindScape sederhana dan ramah pengguna, tetapi masih cukup fleksibel dan mampu. Ini memiliki permukaan desainer seperti L2S / EF dan implementasi UnitOfWork.


LightSeed dari MindScape terlihat sangat menarik.
Nickz

1

Yah, tidak ada pilihan "terbaik" tapi saya akan mengatakan bahwa Linq lama ke SQL memenuhi kebutuhan Anda. Ini bukan ORM "benar", tetapi sangat ringan dan memberi Anda fleksibilitas untuk menulis kode tanpa menyadarinya, jika itu masuk akal. Maksud saya adalah bahwa Anda dapat terus menulis kode seperti biasa, tanpa harus benar-benar menyadari Linq selain memiliki dbmlfile (s). Anda masih bisa menulis abstraksi atasnya, menggunakan pola Repositori atau Gateway, dan L2S memenuhi peran utama ORM, yaitu untuk menyiasati Object-Relational Mismatch.

Entity Framework sedikit berat, dan sementara saya hanya mencoba-coba sedikit, itu lebih "di wajah Anda" daripada Linq dasar untuk Sql, tetapi EF jauh lebih ORM benar daripada Linq. Saya akan melihat semua kriteria yang Anda cari dalam ORM. Apakah hanya karena Anda ingin menghindari harus menulis SQL mentah atau, lebih buruk lagi, memiliki ratusan Prosedur Tersimpan? Apakah Anda memerlukan beberapa fitur tambahan yang tidak dapat disediakan Linq mentah ke Sql? Anda perlu menjawab pertanyaan-pertanyaan itu, tetapi berdasarkan persyaratan singkat Anda ("ringan dan mudah digunakan") Saya pikir Linq sedikit lebih mudah daripada sesuatu seperti Subsonic, dan terintegrasi dengan Visual Studio.


0

ECO :) Ini lebih dari sekedar ORM sementara termasuk mesin negara dan dukungan OCL (yaitu EAL) yang dapat dieksekusi. Ada versi gratis dengan batasan 12 kelas domain yang menurut saya cukup rapi untuk proyek kecil.


4
Akan sangat membantu jika Anda menjelaskan alasannya.
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.