Apakah CodeFirst ditujukan untuk aplikasi skala besar?


16

Saya telah membaca Entity Framework, khususnya, EF 4.1 dan mengikuti tautan ini ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) dan panduannya tentang Code First.

Saya merasa rapi tetapi saya bertanya-tanya, apakah Code First seharusnya hanya menjadi solusi untuk pengembangan cepat di mana Anda bisa langsung masuk tanpa banyak perencanaan atau apakah itu sebenarnya dimaksudkan untuk digunakan untuk aplikasi skala besar?


Saya pikir pendekatan kode-pertama lebih cocok untuk mengejek. Jadi, ini lebih ramah uji.
Gulshan

9
Code-first, paling tidak, teknologi yang sangat baik untuk membuat DBA Anda menjadi busa yang tak terkendali. Jadi, tidak semuanya buruk.
3Sphere

Jawaban:


17

Saya mungkin memiliki beberapa pencela di luar sana, tetapi ketika saya membaca beberapa posting dari Hanselman dan Gutherie, kemudian membaca buku Julia Lerman tentang Entity Framework, saya benar-benar mengalami kesulitan dengan kode terlebih dahulu. Selama bertahun-tahun membangun aplikasi, saya telah menempuh banyak jalur, baik dipaksakan oleh proses, maupun karena pilihan, dan telah menemukan bahwa saya memiliki lebih banyak kesuksesan ketika mengambil tampilan data-sentris saat membangun aplikasi.

Saya sedang berbicara tentang lini aplikasi bisnis di sini ... ini adalah ketika Anda memiliki masalah bisnis atau proses yang perlu memiliki solusi perangkat lunak di belakangnya. Anda memiliki data yang perlu dikelola dengan cara tertentu. Lebih baik untuk mengetahui data Anda dan bagaimana hubungannya dengan dirinya sendiri dan bagaimana data itu digunakan dalam bisnis. Oleh karena itu, Anda memodelkan data itu, dan kemudian membuat aplikasi / solusi di sekitarnya. Dalam pengalaman saya, jika Anda mulai membuat aplikasi dengan data sebagai renungan, sesuatu akhirnya ditinggalkan, dan kemudian Anda memiliki beberapa refactoring (dalam banyak kasus - refactoring UTAMA).

Aplikasi kecil mungkin pengecualian, tetapi saya akan terus menggunakan pendekatan data-sentris saya.


2
Ini mungkin karena pendekatannya masih sedikit asing bagi saya dan saya mungkin berubah pikiran nanti, tetapi bahkan untuk aplikasi kecil, saya merasa masih akan lebih nyaman membangun dari database terlebih dahulu. Tampaknya ini adalah titik paling logis untuk memulai.
RoboShop

5
Bahkan ketika Anda mendasarkan database Anda pada CodeFirst, Anda masih menggunakan pendekatan data-sentris. Anda hanya memodelkan data Anda menggunakan .Net kelas daripada database yang ketat. Jika Anda dapat memodelkan data Anda dalam kelas .net, yang harus Anda lakukan bagaimanapun juga untuk mengetahui cara menggunakan data, maka saya tidak melihat bagaimana itu merupakan rintangan utama untuk membiarkan EF membuat skema untuk mendukung model data itu.
KallDrexx

1
Saya juga ingin menambahkan bahwa kecuali Anda berada di EF 5.0+ dan .NET 4.5+ memilih Code First akan menempatkan batasan kinerja pada aplikasi Anda karena tidak dapat menghasilkan objek CompiledQuery. Saat ini saya sedang dalam proses memindahkan aplikasi dari CodeFirst ke Database Pertama karena kami terjebak dengan EF 4.3
Esteban Brenes

Masalah bisnis menyiratkan proses bisnis, yang menyiratkan perilaku. Data biasanya merupakan efek samping dari perilaku itu (kecuali jika Anda berbicara tentang aplikasi CRUD sederhana), jadi menurut pendapat saya lebih baik fokus pada perilaku pemodelan terlebih dahulu, daripada pada pemodelan DB terlebih dahulu.
Stefan Billiet

5

Saya tidak mengerti mengapa CodeFirst tidak dapat digunakan dalam proyek perusahaan besar. Saya akan mengatakan bahwa saya menggunakan EF CodeFirst di beberapa proyek, di mana basis data dihasilkan oleh model EF CodeFirst saya dan ke 2 di mana EF CodeFirst dipetakan ke basis data yang ada.

Dari pengalaman saya, seberapa efektif CF dalam proyek besar sangat tergantung pada seberapa abstrak lapisan data Anda dari lapisan bisnis Anda.

Sebagai contoh, di salah satu proyek saya, lapisan bisnis secara langsung memanggil basis data melalui LINQ. Saya menggunakan Linq untuk mengabstraksi lapisan basis data saya dan menggunakan CodeFirst untuk memetakan POCO saya ke dalam skema basis data. Dalam hal ini CodeFirst membuat tindakan mempertahankan perbedaan antara konvensi DB (nama hubungan dan tabel) dan kelas C # saya jauh lebih mudah, dan saya dapat membuat perubahan basis data tanpa harus sangat memengaruhi bagaimana lapisan bisnis saya berinteraksi dengan basis data.

Namun, dalam proyek lain saya telah mengabstraksi akses database ke dalam pola repositori non-generik, dan metode Get * repositori saya sepenuhnya bertanggung jawab untuk menjalankan kueri pada database, dan mereka mengembalikan objek nyata (bukan IQueryable<T>s). Dalam hal ini, metode repositori mengubah entitas DB menjadi entitas POCO dan dalam hal ini CodeFirst tidak memberikan banyak manfaat bagi Anda karena POCO CodeFirst berumur pendek dan dengan cepat dikonversi menjadi kelas lapisan bisnis C #.

Pada akhirnya, itu benar-benar tergantung pada bagaimana tim disusun dan seberapa nyaman tim (atau senior) dengan insinyur non-DBA memodifikasi skema database, dan berapa banyak perubahan skema yang akan mempengaruhi struktur kode Anda. Dengan CodeFirst yang dipetakan ke database yang sudah ada, sangat sepele bagi saya untuk memetakan ulang sebuah properti ke nama kolom baru tanpa harus melakukan perubahan nama global dari nama properti itu, yang terutama merupakan faktor ketika Anda berbicara tentang nama yang lebih masuk akal untuk bidang database daripada properti C #. Juga sepele bagi saya untuk menambahkan dukungan kode untuk bidang basis data baru tanpa harus merombak sepenuhnya entitas C # saya (salah satu alasan saya meninggalkan Linq-to-sql ke EF CodeFirst dari basis data yang ada).


4

Code First tidak cocok untuk aplikasi skala besar. Perputaran pengembangan aplikasi skala besar sangat besar.

Seperti siklus hidup aplikasi bisnis Anda,

  1. Versi 1 sedang dalam produksi
  2. Versi 2 dalam versi beta
  3. Versi 3 sedang dalam pengembangan aktif
  4. Versi 4 sedang dalam perencanaan.

Dan ada jembatan komunikasi Cross Application lainnya, beberapa tugas terjadwal, beberapa integrasi pihak ketiga, layanan web untuk beberapa perangkat komunikasi yang berbeda seperti ponsel, dll.

Akhirnya Code First menggunakan ObjectContext Entity Model, EF lama menghasilkan EDMX dan menggunakan ObjectContext dengan EntityObject benar-benar cukup untuk semuanya. Anda dapat dengan mudah menyesuaikan template teks untuk menghasilkan kode. Metode Deteksi Perubahan lebih lambat dengan penerapan ObjectContext, tetapi alih-alih menghasilkan proksi, tim EF dapat dengan mudah meningkatkan kecepatan Deteksi Perubahan daripada menciptakan kembali kode terlebih dahulu.

Migrasi Otomatis

Migrasi Otomatis terdengar bagus secara teori, tetapi mustahil dalam praktiknya begitu Anda ditayangkan. Ini hanya baik untuk membuat prototipe, mengembangkan beberapa demo cepat.

Migrasi Kode Pertama sama sekali tidak cocok dalam sistem tersebut. Versi 1 dan Versi 2 kemungkinan besar berbicara dengan database yang sama. Versi 3 dan Versi 4 biasanya pementasan dan memiliki basis data yang berbeda.

Database Pertama

Database Pertama adalah pendekatan praktis, mudah untuk membandingkan dan memvisualisasikan dan memelihara SQL Script. DBA dapat bekerja dengan mudah.

Template Teks

Kami membuat Template Teks kami sendiri untuk mencari dan membuat EDMX dan ObjectContext dengan sedikit implementasi kustom yang mengatasi masalah kinerja. Ada beberapa aplikasi dengan beberapa versi berkomunikasi ke database yang sama tanpa masalah.

Bagi saya, mengklik kanan pada file .tt dan mengklik "Run Custom Tool" adalah langkah yang paling cepat dan termudah kemudian menulis kelas, mengkonfigurasi dan membuat model.


Migrasi dimaksudkan tepat untuk skenario yang Anda gambarkan.
Casey

Semua migrasi dilakukan (dan mereka tidak harus berjalan secara otomatis) menggambarkan serangkaian perubahan basis data yang ingin Anda buat dalam kode. Jika tidak ada konflik antara model lama dan yang baru (atau Anda tidak memerlukan perubahan database sama sekali) maka tidak ada alasan mengapa Anda tidak dapat memiliki dua versi menggunakan database yang sama.
Casey

2
@ Casey JIKA besar, ketika mempertimbangkan masa berlaku aplikasi :)
BVernon

3

Biasanya untuk proyek-proyek besar database telah dibuat. Entah karena itu adalah basis data warisan atau dibuat oleh dba yang kompeten untuk kinerja. Satu-satunya manfaat dari CodeFirst adalah jika Anda tidak ingin menggunakan entitas EF melainkan POCO.


2

Kedengarannya bagi saya seperti "Code First" dimaksudkan untuk menggunakan EF dengan lebih "gesit" (jangan kecapi terlalu banyak pada istilah itu, saya tidak harus berarti metodologi) dan aplikasi greenfield, di mana Anda tidak memiliki model data yang ada atau data yang ada; jenis aplikasi yang Anda juga bisa menggunakan Django, atau kerangka kerja PHP, atau Rails untuk mengikuti pedoman kerangka kerja yang biasanya melibatkan pembuatan model data sebagai bagian dari kode, alih-alih membangun aplikasi di sekitar model data yang tradisional Cara Microsoft menangani berbagai hal.

Jadi untuk menjawab pertanyaan saya akan mengatakan tidak; jika Anda sudah memiliki data yang ada dan Anda sedang membuat aplikasi untuk menanganinya, Code First tidak masuk akal. Namun, dan saya belum pernah menggunakan EF sama sekali, apalagi Code First EF, sepertinya ini adalah pendekatan yang lebih longgar untuk kode yang selalu bermanfaat. Dengan asumsi Anda dapat menggunakan Kode Pertama dan kemudian masih mengarahkan kelas ke model data yang ada (bukannya dipaksa untuk menghasilkan model) pendekatan Kode Pertama masih bisa membantu untuk menulis kode yang diabstraksi dan diuji dengan baik tanpa semua "kesalahan" penggunaan Entity Framework (yaitu metaclasses yang dihasilkan).


Saya memiliki aplikasi yang berjalan dengan 400+ dan semua dibuat menggunakan pendekatan kode EF terlebih dahulu, saya bisa menggunakan abstraksi, pewarisan jauh lebih mudah daripada pendekatan pemodelan lainnya (Database pertama, model pertama), saya menyarankan untuk menggunakan pendekatan kode pertama sejak itu akan memberi Anda kontrol atas kode dan mudah dipelihara, dan Anda tidak akan kehilangan apa pun dalam hal kinerja dan waktu pengkodean.
Monah

1

Saya akan mengatakan dalam proyek yang sangat besar, kode-pertama tidak masuk akal.

Bahkan, ketika proyek menjadi sangat besar, Anda sering memiliki pemisahan perhatian yang ketat. Anda tidak dapat memiliki orang yang sama menulis kode C #, melakukan desain database, menulis HTML / CSS dan melakukan desain visual di Photoshop. Sebaliknya, desain basis data dilakukan oleh administrator basis data (atau setidaknya oleh orang yang berdedikasi yang mengetahui pekerjaannya).

Karena basis data dirancang oleh orang yang terbiasa dengan basis data, SQL dan administrasi dan alat desain basis data, akan aneh melihat orang ini menggunakan Entity Framework.

Selain itu, saya tidak yakin apakah Entity Framework cukup kuat untuk mendesain database dengan benar. Bagaimana dengan indeks? Kendala? Tampilan?


Hai, ya, itulah yang saya pikirkan. Saya pikir saya kira itu rapi, tapi saya tidak benar-benar melihat keuntungan dari melakukannya seperti dulu, yaitu mendesain database terlebih dahulu. Saya hanya ingin memastikan bahwa itu bukan karena ada sesuatu yang tidak saya pahami.
RoboShop

Kami menambahkan pustaka ekstensi untuk proyek kami yang sangat besar yang memungkinkan kami untuk membuat anotasi indeks pada entitas kode-pertama - berfungsi dengan baik dan relatif mudah dibuat.
Casper

1

Kode pertama dapat dijalankan bahkan untuk sistem besar: Cukup periksa model setelah pembuatan dan remap menggunakan api fasih sampai Anda mencapai model db yang Anda suka.

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.