Apa sajakah argumen MELAWAN menggunakan EntityFramework? [Tutup]

31

Aplikasi yang saya bangun saat ini telah menggunakan prosedur tersimpan dan model kelas kerajinan tangan untuk mewakili objek database. Beberapa orang menyarankan menggunakan Entity Framework dan saya mempertimbangkan untuk beralih ke itu karena saya tidak terlalu jauh ke dalam proyek. Masalah saya adalah, saya merasa orang-orang yang berdebat untuk EF hanya memberi tahu saya sisi baiknya, bukan sisi buruknya :)

Kekhawatiran utama saya adalah:

Kami ingin validasi Sisi Klien menggunakan DataAnnotations, dan sepertinya saya harus membuat model sisi klien jadi saya tidak yakin EF akan menghemat banyak waktu pengkodean
Kami ingin menjaga kelas sekecil mungkin ketika melewati jaringan, dan saya telah membaca bahwa menggunakan EF sering menyertakan data tambahan yang tidak diperlukan
Kami memiliki lapisan basis data yang kompleks yang melintasi beberapa basis data, dan saya tidak yakin EF dapat menangani ini. Kami memiliki satu database umum dengan hal-hal seperti Pengguna, Kode Status, Jenis, dll, dan beberapa contoh dari basis data utama kami untuk berbagai contoh aplikasi. SELECT queries dapat dan akan melakukan query di seluruh instance dari database, namun pengguna hanya dapat memodifikasi objek yang ada dalam database yang sedang mereka kerjakan. Mereka dapat mengganti basis data tanpa memuat ulang aplikasi.
Mode objek sangat kompleks dan sering ada beberapa gabungan yang terlibat

Argumen untuk EF adalah:

Konkurensi. Saya tidak perlu kode cek untuk melihat apakah catatan telah diperbarui sebelum setiap penyimpanan
Pembuatan Kode. EF dapat menghasilkan model kelas parsial dan POCO untuk saya, tetapi saya tidak yakin ini akan sangat menghemat waktu karena saya pikir kita masih perlu membuat model sisi klien untuk validasi dan beberapa metode penguraian khusus.
Kecepatan pengembangan karena kita tidak perlu membuat prosedur tersimpan CRUD untuk setiap objek basis data

Arsitektur kami saat ini terdiri dari Layanan WPF yang menangani panggilan basis data melalui Prosedur Tersimpan parameter, objek POCO yang pergi ke / dari layanan WCF dan klien WPF, dan klien desktop WPF itu sendiri yang mengubah POCO menjadi Model kelas untuk tujuan Validasi dan Pengikatan Data.

Jadi pertanyaan saya adalah, apakah EF tepat untuk ini? Apakah ada jebakan tentang EF yang tidak saya sadari?

architecture orm entity-framework

— Rachel
sumber

Lihat ini juga .. perbandingan kinerja dan dukungan LINQ: ormeter.net

— M.Sameer

7

Baru-baru ini saya mengevaluasi Entity Framework dan tempat terbaik yang saya temukan untuk masalah dan fitur yang hilang adalah: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Item dengan suara terbanyak:

Dukungan untuk enum. Yang ini cukup besar, tetapi saat ini ada beberapa solusi
Peningkatan generasi SQL. Kecepatan sangat penting terutama untuk aplikasi tingkat perusahaan, tetapi sepertinya dengan EF4, kecepatannya telah meningkat pesat
Dukungan untuk banyak basis data. Persyaratan untuk aplikasi besar apa pun.

Ada banyak masalah lagi dalam daftar Suara Pengguna.

Sebagai tambahan, saya cukup senang dengan rilis EF 4.1 yang akan datang yang akan mencakup pendekatan Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-kandidat-available.aspx

Ini mungkin mendorong saya untuk mencoba EF dalam aplikasi produksi.

— Mag20
sumber

Argumen melawan: 1 & 2 & 3: Ini SLOW !!! Ada kurva belajar (perlu tahu bagaimana melakukan join kiri - membutuhkan 3 jam untuk mengetahui cara melakukannya sehingga orang lain akan tahu apa yang sedang dilakukan ...), paging dalam LINQ bukan SQL (mis. Feches 10 juta baris, lalu ambil 20 di antaranya dari offset acak, dan kemudian Anda bertanya-tanya mengapa lambat) ... Repo aman untuk Non-Tapak, Anda harus memasukkannya berdasarkan permintaan, dan inisialisasi repo adalah SANGAT LAMBAT (seperti 5 detik) jika Anda memiliki database yang lebih besar (itu berarti 100-200 tabel, tidak BENAR-BENAR BENAR-BENAR besar).

— Quandary

2

@Quandary Sepertinya Anda menjalankan IQueryables (mis. Menelepon .ToList()atau .ToArray) sebelum ekspresi LINQ Anda sepenuhnya ditentukan. Itu sebabnya ia menarik semua catatan dan membuatnya lambat.

— orad

6

Melakukan branch-per-bug / fitur dengan EF bisa sangat menyakitkan pada saat digabung. Bayangkan bahwa dua cabang A dan B membuat perubahan pada basis data (yang mungkin akan banyak terjadi pada tahap awal proyek baru).

Anda menggabungkan semua file "normal" - file cs, dll. Dan sekarang saatnya untuk menggabungkan Model.edmx. Dan tiba-tiba Anda tidak hanya menggabungkan pemetaan logis antara model objek dan database Anda, tetapi juga posisi tabel dalam diagram entitas.

Menggabungkan Model.edmx sangat menyakitkan sehingga kami mengadopsi Cara yang Cukup Buruk:

Selama penggabungan, cukup pilih semua penggabungan dari satu induk. Yang tidak masalah; Anda akan bersulang file segera:
Kembalikan Model.edmx ke salah satu induk.
Migrasikan basis data Anda ke status gabungan yang baru.
Buka Model.edmx, dan "Perbarui Model dari Database".
Ganti nama semua properti navigasi yang dipanggang selama penggabungan.

— Frank Shearar
sumber

1

Kritik ini tidak berlaku untuk EF Code First tetapi berlaku untuk Model First dan Database First.

— Alan Macdonald

Saya membuat semua pemetaan sendiri menggunakan Fluent dan mengambil kendali penuh atas pemetaan. Ini ditempatkan di dalam file .cs terpisah.

— Steven Ryssaert

5

Ada beberapa manfaat lain untuk EF yang Anda lewatkan:

Anda dapat memiliki tabel rentang Entitas
Anda dapat membagi tabel menjadi banyak jenis Entitas
Anda dapat menghasilkan Entitas dari database (mis. Database sebagai pendekatan master)
Anda dapat menghasilkan database dari Entitas (yaitu kode sebagai pendekatan master)
Kueri LINQ diterjemahkan ke kueri SQL, meningkatkan kinerjanya.

Kerugiannya (terutama jika Anda menggunakan validasi):

Anda harus membuat atribut [MetadataClass] yang menunjuk ke kelas lain yang memiliki properti yang ingin Anda validasi dengan atribut validasi yang sesuai. Semua properti adalah objecttipe, jadi hanya ada di sana untuk membaca metadata. Masih banyak kode ekstra tidak aktif.
Menggunakan EntityFramework adalah konsep yang berbeda dari cara sesuatu seperti NHibernate (dan juga versi induk Java) dirancang untuk bekerja. EntityFramework melakukan yang terbaik dalam mode terlampir di mana objek menggunakan koneksi langsung setiap saat. NHibernate dan alat ORM serupa berfungsi paling baik dalam mode terpisah di mana koneksi hanya digunakan saat memuat / menyimpan data.

Itu adalah dua keluhan terbesar yang saya miliki. Ada sejumlah manfaat, tetapi Anda mungkin bisa mendapatkan manfaat yang sama dari NHibernate. Jika EntityFramework ada di atas meja, minta tim juga memeriksa NHibernate dan melakukan pemotretan cepat untuk pro / kontra untuk proyek Anda .

Masalah kelas metadata adalah sakit kepala, tapi untungnya saya hanya memiliki begitu banyak entitas yang memerlukan tag validasi.

Kurangnya mode terpisah yang benar untuk objek Anda membatasi apa yang dapat Anda lakukan di lingkungan web. Mode terlampir lebih baik untuk aplikasi desktop, yang merupakan tempat sejumlah inovasi Microsoft berasal. Mode terlepas mungkin , tetapi sangat menyakitkan. Cara terbaik untuk menggunakan alat alternatif dalam hal ini.

— Berin Loritsch
sumber

Kode yang Anda sebut sebagai pendekatan master secara resmi disebut kode pertama

— Robert Koritnik

1

@Berin, saya ingin menjelaskan apa yang Anda maksud dengan "mode terlampir". Saya tidak berpikir bahwa Entity Framework memiliki koneksi ke database terbuka setiap saat. Saya percaya EF bekerja mirip dengan NHibernate dalam hal ini. Apakah ini yang Anda maksudkan atau maksud Anda sesuatu yang lain? Apakah Anda memiliki tautan ke dokumentasi yang menjelaskan masalah terlampir ini lebih lanjut?

— RationalGeek

1

Dengan terpasang, maksud saya semua interaksi Anda dengan benda harus berlangsung dalam satu using(EFConnection conn = new EFConnection)konstruk. Jika Anda mencoba untuk menyembunyikan objek itu di suatu tempat agar tetap aman sehingga Anda dapat melakukan pembaruan cepat dan menyimpannya lagi dalam using(...)pernyataan kedua , Anda harus berpikir lagi. Lihat msdn.microsoft.com/en-us/library/bb896271.aspx dan msdn.microsoft.com/en-us/library/bb896248.aspx . Menggunakan EF 3.5 (yang harus saya gunakan pada versi terakhir) bahkan tidak sebersih itu.

— Berin Loritsch

Oke saya mengerti maksud Anda sekarang. Saya hanya ingin memastikan orang tidak menganggap itu berarti bahwa selalu ada koneksi ke database . Anda harus memiliki konteks objek yang mempertahankan status entitas "terlampir".

— RationalGeek

2

Ini tidak benar. EF memiliki gagasan kuat tentang entitas yang terpisah. Entitas yang terpisah harus disambungkan kembali ke konteksnya sebelum Anda dapat melakukan operasi terkait konteks terhadapnya (seperti memperbaruinya dalam database). Juga kelas metadata hanya diperlukan jika EF menghasilkan entitas Anda untuk Anda. POCO, IMO, adalah cara yang jauh lebih baik untuk menggunakan EF. Menggunakan POCO membuat banyak hal lebih sederhana, dalam pengujian tertentu.

— Matt Greer

2

Satu hal Microsoft tidak sangat baik di adalah mundur ~~komparabilitas~~ kompatibilitas, terutama ketika datang ke teknologi baru

Khususnya EF1 (.net 3.5) sangat berbeda dari EF4 (.net 4.0) - hal yang sama mungkin terjadi untuk versi berikutnya.

Saya akan menunggu sebentar dan melihat bagaimana teknologi matang.

Sementara itu, pertimbangkan untuk menggunakan nHibernate - ini tidak setara, tetapi sudah matang dan digunakan secara liar.

— Ophir Yoktan
sumber

1

Cukup ... Model Domain jarang merupakan replika model relasional dalam database Anda. Jadi, memetakan beberapa meja ke kelas dan melemparkannya ke atas kawat hanyalah kemalasan biasa. Tabel mungkin memetakan secara lokal menjadi 1 objek meskipun database adalah 3 tabel berbeda. Desain basis data secara cerdas.
Kedua, hal-hal EF ini tidak dapat menghasilkan pertanyaan tertentu dan Anda harus tetap menulisnya.
3 Model Domain tidak memetakan langsung ke layanan .. Seseorang hanya akan ingin mendorong set data paling minimal melalui kabel sebagai DTO .. terutama, jika itu akan berkomunikasi dengan aplikasi seluler.
Tes 5-kemampuan ... Tidak dapat membuat tes cukup granular yang akan memberikan regresi yang cukup terhadap perubahan kode ... semua mudah untuk
...

Saya bisa menulis cacian 10 halaman. Tapi, jika Anda hanya menulis beberapa aplikasi membuang untuk Perusahaan X .. yang peduli saat itu. Tetapi, jika Anda mengembangkan produk perangkat lunak ... Anda harus menjadi lebih anal

— pengguna104468
sumber

posting ini agak sulit dibaca (dinding teks). Maukah Anda mengeditnya menjadi bentuk yang lebih baik?

— nyamuk

EF tidak menghasilkan objek domain. Itu adalah DAO. Anda harus menggunakan data dari objek untuk membuat objek domain Anda. Anda seharusnya tidak mengirim objek domain kembali dari layanan, jadi buat DTO yang lebih tipis dari objek domain Anda sebelum kembali. EF harus dapat menghasilkan sebagian besar apa pun yang dapat Anda ungkapkan dalam LINQ. Basis data bukan bagian dari unit test, ini bagian dari tes fungsional. Yang mengatakan, ada memori yang tersedia untuk EF. Kalau tidak, abaikan permintaan EF Anda ke repositori dan kemudian tiru itu.

— Sinaesthetic

Ya, saya setuju. Sebelumnya, saya mengacu pada pola yang ditetapkan oleh Martin Fowler dan Carig Lairman. Pada akhirnya, saya tidak dapat menggunakan CTE, PARTITION BY atau CROSS APPLY. Saya juga, tidak bisa menggunakan IDataReader yang memungkinkan seseorang untuk menjaga overhead memori rendah. Juga, ketika saya menjalankan SQL Trace dan melihat apa yang dikirimkan EF melalui kawat saya merasa seolah-olah saya akan melemparkan ;-)

— user104468

0

Lihat ini: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Poin utamanya adalah:

Kurang memuat malas
Kurangnya ketidaktahuan kegigihan
Format file yang digunakan untuk menyimpan model entitas berisi elemen visualisasi dan model entitas itu sendiri menyebabkan masalah gabungan di lingkungan tim.

Perhatikan bahwa tautan di atas berbicara tentang EF1.

Juga tautan ini: http://ormeter.net/ menunjukkan bahwa EF bukan yang terbaik dibandingkan dengan ORM lain dalam kinerja dan dukungan LINQ.

— M.Sameer
sumber

Ingatlah bahwa ini diposting ketika EF 1 masih baru dirilis (atau mungkin masih dalam versi beta). Situasinya jauh lebih baik hari ini dengan EF 4, dan banyak masalah yang diangkat dalam mosi tidak percaya telah diselesaikan.

— RationalGeek

Poin terakhir masih diperhitungkan dan sangat signifikan.

— M.Sameer

1

Versi EF pertama adalah 3.5. Belum ada empat versi utama EF yang dirilis.

— Matt Greer

3

@ Mat itu benar. Tetapi versi saat ini disebut EF 4 untuk menyelaraskan dengan sisa versi .NET 4.

— RationalGeek

1

Apakah itu valid atau tidak seharusnya tidak memengaruhi ringkasan tautan. Suara akan ditampilkan jika valid. :)

— Adam Lear