Haruskah kita menggunakan Entity Framework?

31

Saat ini kami memiliki tumpukan berikut:

VS 2005
Formulir web
SQL Server 2005
IIS 6

Kami berencana untuk beralih ke ini:

VS 2010
Formulir MVC dan Web
SQL Server 2008
IIS 7

Pertanyaan saya adalah, ketika kita pindah ke MVC dengan VS 2010, haruskah kita menggunakan Entity Framework (atau ORM lain), ORM mikro (seperti Massive ), atau sekadar SQL?

Semua tutorial yang saya baca tentang VS 2010 semuanya diarahkan untuk menggunakan Entity Framework untuk transaksi data, tetapi apakah itu akan ada di masa mendatang (5+ tahun)?

Jika itu penting, aplikasi klien kami dapat memiliki 10 - 1.000 pengguna aktif.

— guanome
sumber

Apakah Anda menggunakan Linq-to-SQL saat ini?

— Morgan Herlocker

Kami menggunakan parameterized SQL

— guanome

4

Hindari menggunakan SQL secara langsung dalam pengembangan masa depan Anda. ORM atau EF hampir merupakan keharusan. Luangkan waktu untuk memiliki strategi untuk lapisan akses data Anda. Ini adalah keputusan kritis dan itu bukan tugas sepele. Pastikan Anda memiliki cukup waktu untuk Anda dan tim untuk mempelajarinya. Pengenalan teknologi inti baru ke tim harus dikelola. Pilih alat, pilih bahan, dapatkan pendidikan, ..., lalu evaluasi dan putuskan.

— NoChance

2

Database baru atau yang sudah ada? Ada potensi perbedaan besar antara membangun DB baru dengan konvensi EF, dan mencoba untuk menyesuaikan EF di atas DB yang ada yang tidak dibuat untuk ORM.

— rmac

@rmac Itu untuk database baru.

— guanome

45

Saya baru-baru ini beralih dari menggunakan kueri SQL sebaris ke menggunakan EF dan inilah yang saya temukan:

Pro

Jauh lebih cepat untuk membangun DAL (suka tidak menulis pertanyaan SQL!)
Jauh lebih mudah dirawat
Tidak perlu lagi mengingat input saya sebelum membangun in-line sql statement, yang berarti lebih sedikit kemungkinan serangan injeksi SQL (tentu saja, itu masih mungkin tergantung pada permintaan Anda, tetapi sangat kecil kemungkinannya)

Cons

Tidak dapat menjangkau beberapa basis data ... setidaknya tidak dengan mudah
Semua entitas (tabel, tampilan, dll) memerlukan kunci utama
Jika Anda ingin memperbarui satu kolom dalam tabel 100 + kolom yang diperlukan (bukan desain tabel saya), Anda harus menarik ke bawah semua 100 kolom untuk melakukan pembaruan. Atau gunakan Prosedur Tersimpan.
Saya punya masalah dengan beberapa nilai default yang didefinisikan pada SQL server tidak ditarik ke model entitas setelah catatan baru ditambahkan. Biasanya ini dengan nilai yang dihitung, atau nilai yang ditambahkan dalam Pemicu INSERT
Kadang-kadang, query SQL ditulis dengan buruk dan lambat untuk dieksekusi. Jika Anda memiliki kueri yang berjalan lambat, jalankan pelacakan SQL untuk melihat apa yang dilakukan EF. Mungkin saja Anda dapat mengerjakan kembali kueri itu sebagai SP atau Tampilan. Ini tidak terjadi sesering itu.
Saya punya beberapa masalah dengan mencoba membuat hubungan antara tabel yang tidak memiliki kunci asing yang didefinisikan dalam SQL Server. Biasanya itu karena saya mencoba membuat 1:0-1hubungan di mana EF ingin menggunakan1:0-*

Saya bukan ahli EF, jadi saya mungkin melewatkan beberapa hal. Ini hanya item yang saya tahu saya temui di masa lalu ketika beralih dari inline SQL ke Entity Framework. Saya senang saya beralih, tetapi ada saat-saat ketika saya benar-benar membenci EF karena keanehannya.

— Rachel
sumber

7

+1 untuk jawaban terinci dan terorganisir. "Semua entitas (tabel, tampilan, dll) memerlukan kunci primer" terdengar seperti pembatasan yang masuk akal daripada sebuah con.

— NoChance

2

@EmmadKareem Ini adalah pembatasan yang ok jika Anda memiliki kendali atas basis data, tetapi jika Anda bekerja dengan basis data pihak ketiga, atau dengan tampilan, ini bisa sedikit mengganggu

— Rachel

1

Coba gunakan EF di aplikasi web N-Tier yang terputus - memperbarui entitas dalam sesi dan hubungan MM, hmmmmm apa yang menyenangkan!

— Vidar

5

Entitas @EmmadKareem benar-benar membutuhkan kunci primer bernilai tunggal - menggunakan kunci komposit adalah mimpi buruk di EF. Ini adalah tipuan dan bukan batasan yang masuk akal.

— Kirk Broadhurst

1

Saya akan mengatakan keamanan adalah masalah lain. Banyak yang berpikir bahwa semua akses DB harus melalui prosedur tersimpan dengan peran DB yang terkait dengan procs untuk menentukan login apa yang dapat menjalankan procs yang disimpan. Ini mengesampingkan EF / LINQ untuk membuat kueri. Saya telah menggunakan EF tetapi telah menjumpai klien ( batuk Microsoft) yang memiliki persyaratan keamanan ini

— Mick

12

Entity Framework adalah alat produktivitas. Kecuali Anda memiliki alasan kuat untuk tidak (misalnya Anda menggunakan SQL 2000 atau tidak punya waktu untuk meningkatkan teknologi), maka gunakan alat terbaik yang Anda inginkan.

Yang sedang berkata, saya menemukan konsep Entitas untuk menerjemahkan dengan sangat baik untuk Model pola MVC. Walaupun memiliki hubungan 1: 1 dengan Model dan tabel adalah praktik yang buruk, berpikir dalam hal Entitas cenderung menghasilkan desain yang bersih, kode yang mudah dibaca (terutama dengan LINQ).

Entity Framework didukung secara aktif oleh Microsoft. Tidak ada yang memiliki bola kristal ajaib untuk mengatakan "dukungan akan bertahan X tahun". Saya tidak melihat alasan untuk percaya Entitas akan mati dalam 5 tahun ke depan.

— P.Brian.Mackey
sumber

3

LinqToSql mati cukup cepat, jadi benar-benar tidak ada alasan untuk mempercayai apakah Entity Framework akan bertahan. Sebaiknya pertimbangkan dorongan baru MS terhadap Metro, sebanyak mungkin mereka mempertimbangkan perombakan banyak dari penawaran mereka.

— ocodo

3

Slomojo, mungkin Anda memiliki definisi yang berbeda dari kata "Mati" di dunia. Karena LinqToSql tidak lagi dikembangkan secara aktif. Anda masih dapat menggunakannya 10-20 tahun dari sekarang.

— Boris Yankov

4

Solusi potensial lainnya adalah dengan menggunakan Perpustakaan Entity Framework alternatif yang bukan yang dipasok dengan VS. Ada beberapa di luar sana di web.

Konsep kerangka Entity / 3 lapisan, telah di luar sana untuk sementara waktu, dan telah bekerja dengan beberapa perpustakaan khusus, seperti banyak pengembang lain, sebelum Microsoft merilis kerangka kerja "resmi" sendiri.

Pro

Memiliki manfaat kerangka kerja Entity (DAL), tanpa terjebak dengan perubahan pustaka / kerangka kerja Microsoft yang konstan.

Menambahkan fitur ke perpustakaan yang mungkin tidak tersedia ke perpustakaan resmi yang ada, seperti menggunakan beberapa merek dtabase.

Cons

Harus mendukung perpustakaan atau alat. Sangat umum untuk memiliki alat kode generator Entity untuk menghasilkan enitites.

— umlcat
sumber

Saya menemukan jawaban ini sangat membingungkan. Hanya ada satu Kerangka Entitas (dengan huruf kapital) yang merupakan yang diproduksi oleh Microsoft. Apakah maksud Anda "gunakan mapper relasional objek lain"? Entity Framework bukan istilah umum - itu adalah nama ORM Microsoft.

— NickG

Meskipun ada "Kerangka Kerja Entitas Microsoft", konsep "Kerangka Kerja Entitas" telah ada selama beberapa tahun.

— umlcat

3

Anda harus membuat keputusan arsitektur berdasarkan masalah dan solusi yang ada. Seperti halnya teknologi apa pun ada kelebihan dan kekurangan.

Saya pribadi biasanya akan menggunakan kerangka entitas untuk pengembangan baru tetapi tidak menulis ulang kode yang ada. Anda kemudian mendapatkan kecepatan untuk delelopment di masa depan tetapi tidak perlu menginvestasikan banyak waktu untuk mengonversi kode. Kelemahan dari pendekatan itu adalah ia mengurangi konsistensi.

— Tom Squires
sumber

3

+1 untuk merekomendasikan untuk tidak menulis ulang kode kerja.

— NoChance

2

Dalam situasi Anda, saya pasti akan menggunakan Entity Framework, saya telah menemukan itu berfungsi baik dengan MVC.
Berikut adalah beberapa alasan dan petunjuk nyata.

Linq adalah kesenangan untuk digunakan, dan eksekusi yang tertunda juga sangat berguna.
Anda dapat menghasilkan model Anda (namun ketika menggunakan dengan mvc saya akan merekomendasikan Anda menggunakan model tampilan bersama dengan model data, ini membuat validasi dan model mengikat banyak lebih mudah, jika Anda mengambil pendekatan yang menggunakan automapper untuk memetakan perubahan kembali ke Anda model data).

Ada beberapa hal yang perlu Anda pelajari tentang menggunakan ORM.

Apa konteksnya bagi Anda (pelacakan entitas)
Bahwa konteks harus digunakan sebagai unit kerja
Ingat sesuatu tentang konkurensi, EF dapat memberi tahu Anda ketika objek Anda kedaluwarsa tetapi bisa rumit jika Anda ingin menangani konkurensi dengan benar di seluruh permintaan (karena Anda perlu menyimpan stempel waktu atau sesuatu).

Hal-hal yang perlu dipertimbangkan

Pemicu dan ORM tidak bekerja sama, gunakan acara ORM sebagai gantinya.
Pastikan semua meja Anda memiliki kunci promary.

Saya juga sangat merekomendasikan pendekatan kode pertama, bahkan jika Anda memiliki database yang sudah ada.

Konvensi tersebut berarti Anda tidak perlu memulai kembali pemetaan atau kelas saat Anda mengubah database.
Lebih mudah untuk menempatkan validasi dan logika lain dalam model.
Anda dapat menggunakan pembuat kode untuk membantu membuatnya jika Anda memiliki basis data yang sangat besar.

— Daniel Little
sumber