CodeFirst büyük ölçekli uygulamalar için mi tasarlanmıştır?

Entity Framework'ü, özellikle EF 4.1'i okudum ve bu bağlantıyı takip ediyorum ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) ve First Code ile ilgili kılavuzdur.

Düzgün buluyorum ama merak ediyorum, Code First hızlı planlama için sadece çok fazla planlama yapmadan hemen atlayabileceğiniz bir çözüm mü olmalı yoksa aslında büyük ölçekli uygulamalar için mi kullanılmalıdır?

Orada bazı detraktörler olabilir, ancak Hanselman ve Gutherie'den bu yazıların bazılarını okuduktan sonra Julia Lerman'ın Entity Framework kitabını okuduğumda , önce kodla gerçekten zor bir zaman geçirdim. Yıllarca süren uygulama uygulamalarımda, hem süreç hem de seçim yoluyla zorlanan birçok yoldan geçtim ve bir uygulama oluştururken veri merkezli bir görünüm alırken çok daha başarılı olduğumu keşfettim.

Ben burada iş hattı uygulamaları hakkında konuşuyorum ... bu arkasında bir yazılım çözümü olması gereken bir iş sorun veya süreç olduğunda. Bir şekilde yönetilmesi gereken verileriniz var. Verilerinizi ve verilerin kendisiyle nasıl ilişkilendiğini ve işletme içinde nasıl kullanıldığını bilmek daha iyidir. Bu nedenle, bu verileri modelleyin ve çevresinde bir uygulama / çözüm oluşturun. Benim tecrübeme göre, sonradan düşünülen verilerle uygulama oluşturmaya başlarsanız, bir şey sonunda dışarıda kalır ve sonra bazı yeniden düzenleme (birçok durumda - BÜYÜK yeniden düzenleme) var.

Küçük uygulamalar bir istisna olabilir, ancak veri odaklı yaklaşımımı kullanmaya devam edeceğim.

CodeFirst'in neden büyük kurumsal projelerde kullanılamadığını anlamıyorum. EF CodeFirst'i veritabanının EF CodeFirst modelim tarafından oluşturulduğu ve ikincisinin EF CodeFirst'in mevcut bir veritabanıyla eşleştirildiği birkaç projede kullandığımı söyleyeceğim.

Deneyimlerime göre, büyük bir projede CF'nin ne kadar etkili olduğu, veri katmanınızın iş katmanınızdan ne kadar soyutlandığına bağlıdır.

Örneğin, projelerimden birinde iş katmanı veritabanını doğrudan linq aracılığıyla çağırıyor. Veritabanı katmanımı soyutlamak için Linq ve POCO'ları veritabanı şemasına eşlemek için CodeFirst kullanın. Bu durumda CodeFirst, DB kuralları (ilişki ve tablo adları) ve C # sınıf adlarım arasındaki farkları koruma eylemini çok daha basit hale getirir ve iş katmanımın veritabanıyla etkileşimini önemli ölçüde etkilemek zorunda kalmadan veritabanı değişiklikleri yapabilirim.

Ancak, başka bir projede genel olmayan bir veri tabanı desenine veritabanı erişimini soyutladım ve veri havuzumun Get * yöntemleri yalnızca veritabanında sorgu çalıştırmaktan sorumlu ve gerçek nesneleri döndürüyor (değilIQueryable<T> s ). Bu örnekte, veri havuzu yöntemleri DB varlıklarını POCO varlıklarına dönüştürmektedir ve bu durumda CodeFirst, CodeFirst POCO'larının kısa ömürlü olması ve hızlı bir şekilde iş katmanı C # sınıflarına dönüştürülmesi kadar size bir fayda sağlamaz.

Sonuçta, bu gerçekten takımın nasıl yapılandırıldığına ve DBA dışı mühendisler ile veritabanı şemalarını değiştiren ekibin (veya yaşlıların) ne kadar rahat olduğuna ve kod yapınızı ne kadar şema değişikliğinin etkileyeceğine bağlıdır. CodeFirst varolan bir veritabanıyla eşlendiğinde, özellikle daha anlamlı bir addan bahsederken bir faktör olan bu özellik adının genel bir yeniden adlandırmasını yapmak zorunda kalmadan bir özelliği yeni bir sütun adına yeniden eşlemem önemsizdir. C # özelliği yerine veritabanı alanı için. C # varlıklarımı tamamen yenilemek zorunda kalmadan yeni veritabanı alanları için kod desteği eklemek de benim için çok önemli. (Linq-to-sql'ı mevcut bir veritabanından EF CodeFirst'e bırakmamın nedenlerinden biri).

Birinci Kod büyük ölçekli uygulamalar için uygun değildir. Büyük ölçekli uygulama geliştirme geri dönüşü çok büyük.

Genellikle iş uygulamanızın yaşam döngüsü,

1. Versiyon 1 çıktı
2. Sürüm 2 beta sürümündedir
3. Sürüm 3 aktif geliştirme aşamasında
4. Sürüm 4 planlama aşamasındadır.

Ve diğer Çapraz Uygulama iletişim köprüleri, bazı zamanlanmış görevler, bazı üçüncü taraf entegrasyonu, mobil gibi bazı iletişim aygıtları için web hizmetleri vardır.

Sonunda Code First, Entity Model'in ObjectContext'ini kullanır, EDMX üreten eski EF ve EntityObject ile ObjectContext kullanmak her şey için gerçekten yeterliydi. Kod oluşturmak için metin şablonunu kolayca özelleştirebilirsiniz. Nesneleri Algıla yöntemi ObjectContext uygulamasıyla daha yavaştır, ancak EF ekibi proxy oluşturmak yerine önce kodu yeniden icat etmek yerine Değişiklikleri Algılama hızını kolayca geliştirebilirdi.

Otomatik Taşıma

Otomatikleştirilmiş Geçiş teoride kulağa hoş geliyor, ancak hayata geçtiğinizde pratikte imkansız. Sadece prototip oluşturma, bazı hızlı demolar geliştirme için iyidir.

Kod İlk Göç böyle bir sistemde hiç uygun değildir. Sürüm 1 ve Sürüm 2 büyük olasılıkla aynı veritabanıyla konuşur. Sürüm 3 ve Sürüm 4 genellikle hazırlama ve farklı veritabanı vardır.

Önce Veritabanı

Veritabanı Önce pratik bir yaklaşımdır, SQL Scriptleri karşılaştırmak ve görselleştirmek ve korumak kolaydır. DBA'lar kolayca çalışabilir.

Metin Şablonları

Performans sorunlarını ele alan küçük özel uygulamalarla EDMX ve ObjectContext'i sorgulamak ve oluşturmak için kendi Metin Şablonlarımızı oluşturduk. Herhangi bir sorun olmadan aynı veritabanına iletişim kuran birden çok sürümü olan birden fazla uygulama vardır.

Bana göre, .tt dosyasını sağ tıklayıp "Özel Aracı Çalıştır" ı tıklamak, sınıfları yazıp yapılandırmak ve model oluşturmaktan çok daha hızlı ve kolay bir adımdır.

Genellikle büyük projeler için veritabanı zaten oluşturulmuştur. Ya eski bir veritabanı olduğu ya da performans için yetkili bir dba tarafından oluşturulduğu için. CodeFirst'in tek yararı EF'in varlıklarını değil POCO'ları kullanmak istemenizdir.

Bana "Kod İlk" daha EF "daha çevik" (bu terim üzerinde çok fazla harp etmeyin, metodoloji demek zorunda değilim) ve yeşil alan uygulamaları, mevcut veri modeli veya mevcut veri; geleneksel olarak bir veri modeli etrafında bir uygulama oluşturmak yerine normalde kodun bir parçası olarak veri modelinin oluşturulmasını içeren bu çerçevelerin yönergelerini izlemek için Django veya bir PHP çerçevesi veya Rails kullanabileceğiniz bir uygulama Microsoft işleri halletmenin yolu.

Yani soruyu cevaplamak için hayır diyebilirim; Zaten mevcut verileriniz varsa ve bu verileri işlemek için bir uygulama oluşturuyorsanız, Code First çok anlamlı değildir. Ancak, EF İlk olarak Kod EF'i çok fazla kullanmadım, kod için her zaman faydalı olan daha gevşek bir yaklaşım gibi görünüyor. Önce Kod'u kullanabileceğinizi ve sonra yine de sınıfı mevcut bir veri modeline (modeli oluşturmak zorunda kalmak yerine) işaret edebileceğinizi varsayarsak, İlk Kod yaklaşımı, her zamanki genel kullanımı olmadan düzgün bir şekilde soyutlanmış ve test edilebilir kod yazmaya yardımcı olabilir. Varlık Çerçevesi (yani üretilen metasınıflar).

Gerçekten büyük projelerde, kod ilk önce mantıklı değil.

Aslında, proje gerçekten büyüdüğünde, sık sık endişeleriniz var. Photoshop'ta C # kodu yazma, veritabanı tasarımı yapma, HTML / CSS yazma ve görsel tasarım yapma konusunda aynı kişiye sahip olamazsınız. Bunun yerine, veritabanı tasarımı bir veritabanı yöneticisi (veya en azından işini bilen özel bir kişi) tarafından yapılır.

Veritabanı, veritabanı, SQL ve yönetim ve veritabanı tasarım araçlarını bilen bir kişi tarafından tasarlandığından, Entity Framework kullanan bu kişiyi görmek garip olur.

Dahası, Entity Framework'ün veritabanını düzgün bir şekilde tasarlayacak kadar güçlü olup olmadığından emin değilim. Endeksler ne olacak? Kısıtlamalar? Görüntüleme?

Önce kod büyük sistemler için bile geçerlidir: Sadece modeli oluşturduktan sonra inceleyin ve istediğiniz db modeline ulaşıncaya kadar akıcı api'yi kullanarak yeniden eşleştirin.