Apakah CodeFirst ditujukan untuk aplikasi skala besar?

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

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

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.

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.

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

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.