Önce kod - Model / Veritabanı önce [kapalı]

Varlık Çerçevesi 4.1 İlk Model / Veritabanı üzerinden Kod İlk EDMX şeması ile kullanmanın artıları ve eksileri nelerdir?

EF 4.1 kullanarak veri erişim katmanı oluşturmaya yönelik tüm yaklaşımları tam olarak anlamaya çalışıyorum. Depo desenini kullanıyorum ve IoC.

Önce kod yaklaşımını kullanabileceğimi biliyorum: varlıkları ve bağlamlarımı elle tanımlayın ModelBuilderve şemayı ince ayarlamak için kullanın .

Ayrıca bir EDMXdiyagram oluşturmak ve aynı POCOsınıfları oluşturmak için T4 şablonları kullanan bir kod oluşturma adımı seçebilirsiniz .

Her iki durumda POCOda, ORMagnostik ve bağlamdan türeyen bir nesne ile sonuçlanırım DbContext.

Enterprise Manager'da veritabanı tasarlayabildiğim, modeli hızlı bir şekilde senkronize edebildiğim ve tasarımcıyı kullanarak ince ayar yapabildiğim için, önce veritabanı en çekici görünüyor.

Peki bu iki yaklaşım arasındaki fark nedir? Sadece VS2010 vs Enterprise Manager tercihi ile mi ilgili?

Farklılıklar bence:

Önce kod

• Çok popüler çünkü hardcore programcılar herhangi bir tasarımcıyı sevmiyor ve EDMX xml'de eşleme tanımlamak çok karmaşık.
• Kod üzerinde tam kontrol (değiştirilmesi zor otomatik olarak oluşturulmuş kod yok).
• Genel beklenti, DB ile uğraşmamanızdır. DB sadece mantığı olmayan bir depolama alanıdır. EF yaratılışın üstesinden gelecek ve işi nasıl yaptığını bilmek istemezsiniz.
• Kodunuz veritabanını tanımladığı için veritabanındaki manuel değişiklikler büyük olasılıkla kaybolacaktır.

Önce veritabanı

• DBA'lar tarafından tasarlanan, ayrı olarak geliştirilen DB'niz varsa veya mevcut DB'niz varsa çok popülerdir.
• EF'nin sizin için varlıklar oluşturmasına izin vereceksiniz ve eşlemenin değiştirilmesinden sonra POCO varlıkları oluşturacaksınız.
• POCO varlıklarında ek özellikler istiyorsanız, T4 şablonunu değiştirmeli veya kısmi sınıflar kullanmalısınız.
• Veritabanı etki alanı modelinizi tanımladığından, veritabanında el ile değişiklik yapılması mümkündür. Modeli her zaman veritabanından güncelleyebilirsiniz (bu özellik oldukça iyi çalışır).
• Ben sık sık VS Veritabanı projeleri birlikte kullanın (sadece Premium ve Ultimate sürümü).

Önce model

• Tasarımcı hayranı iseniz popüler IMHO (= kod veya SQL yazmayı sevmiyorsunuz).
• Modelinizi "çizeceksiniz" ve iş akışının veritabanı komut dosyanızı ve T4 şablonunun POCO varlıklarınızı oluşturmasına izin vereceksiniz. Hem varlıklarınızda hem de veritabanınızda kontrolün bir kısmını kaybedeceksiniz, ancak küçük kolay projeler için çok üretken olacaksınız.
• POCO varlıklarında ek özellikler istiyorsanız, T4 şablonunu değiştirmeli veya kısmi sınıflar kullanmalısınız.
• Modeliniz veritabanını tanımladığı için veritabanındaki manuel değişiklikler büyük olasılıkla kaybolacaktır. Veritabanı oluşturma güç paketi yüklüyse, bu daha iyi çalışır. VS'de veritabanı şemasını (yeniden oluşturmak yerine) güncellemenizi veya veritabanı projelerini güncellemenizi sağlar.

EF 4.1 durumunda, önce Code First ile Model / Database arasında bir kaç özellik daha olmasını bekliyorum. İlk olarak Kod'da kullanılan akıcı API, EDMX'in tüm özelliklerini sunmaz. Saklı yordamlar eşleme, sorgu görünümleri, görünümleri tanımlama vb gibi özellikleri ilk Model / Veritabanı kullanırken çalışır ve DbContext(henüz denemedim) ama ilk kod yok.

Sanırım "Programlama Varlık Çerçevesi" nin yazarı Julie Lerman'ın bu basit "karar ağacı", kararın daha güvenle alınmasına yardımcı olmalı:

Daha fazla bilgi Burada .

Önce veritabanı ve önce modelin gerçek bir farkı yoktur. Oluşturulan kod aynıdır ve bu yaklaşımları birleştirebilirsiniz. Örneğin, sql komut dosyasını kullanarak veritabanını değiştirip modelinizi güncelleyebildiğinizden, tasarımcıyı kullanarak veritabanı oluşturabilirsiniz.

Önce kodu kullandığınızda, rekreasyon veritabanı olmadan ve tüm verileri kaybetmeden modeli değiştiremezsiniz. IMHO, bu sınırlama çok katıdır ve üretimde önce kod kullanılmasına izin vermez. Şimdilik gerçekten kullanışlı değil.

Kodun ikinci küçük dezavantajı, model oluşturucunun ana veritabanında ayrıcalıklar gerektirmesidir. SQL Server Compact veritabanı kullanıyorsanız veya veritabanı sunucusunu kontrol ediyorsanız bu durum sizi etkilemez.

Önce kodun avantajı çok temiz ve basit bir koddur. Bu kod üzerinde tam kontrole sahip olursunuz ve bu kodu görünüm modeliniz olarak kolayca değiştirebilir ve kullanabilirsiniz.

Üretimde modifikasyon gerektiren projelerde versiyonlama ve model \ database'i kullanmadan basit bir bağımsız uygulama oluştururken kod ilk yaklaşımını kullanmanızı tavsiye ederim.

İlgili parçaların http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework adresinden alıntılanması

Entity Framework ile ilk kod tasarımını kullanmak için 3 neden

1) Daha az sarsıntı, daha az şişkinlik

Bir .edmx model dosyası ve ilişkili kod modelleri oluşturmak için var olan bir veritabanının kullanılması, dev bir otomatik oluşturulan kod yığını ile sonuçlanır. Bir şeyleri kırmamak için bu oluşturulan dosyalara asla dokunmamanız ya da bir sonraki nesilde değişikliklerinizin üzerine yazılmaması. Bağlam ve başlatıcı da bu karmaşada sıkıştı. Hesaplanan salt okunur özellik gibi oluşturulan modellerinize işlevsellik eklemeniz gerektiğinde, model sınıfını genişletmeniz gerekir. Bu, neredeyse her model için bir gerekliliktir ve her şey için bir uzantı ile sonuçlanırsınız.

Önce kod ile el kodlu modeller veritabanınız olur. Oluşturduğunuz dosyalar veritabanı tasarımını oluşturan dosyalardır. Ek dosya yoktur ve özellikler eklemek istediğinizde veya veritabanının bilmesi gerekmeyen başka ne varsa sınıf uzantısı oluşturmanıza gerek yoktur. Doğru sözdizimini izlediğiniz sürece bunları aynı sınıfa ekleyebilirsiniz. Heck, isterseniz kodunuzu görselleştirmek için bir Model.edmx dosyası bile oluşturabilirsiniz.

2) Daha Fazla Kontrol

İlk önce DB'ye gittiğinizde, uygulamanızda kullanmak için modelleriniz için üretilenlerin merhametindesiniz. Bazen adlandırma kuralı istenmeyen bir durumdur. Bazen ilişkiler ve çağrışımlar istediğiniz gibi olmayabilir. Diğer zamanlarda tembel yükleme ile geçici olmayan ilişkiler API yanıtlarınıza zarar verir.

Karşılaşabileceğiniz model oluşturma sorunları için neredeyse her zaman bir çözüm olsa da, gitme kodu ilk olarak size başlangıçtan itibaren tam ve ince taneli kontrol sağlar. Hem kod modellerinizin hem de veritabanı tasarımınızın her yönünü iş nesnenizin rahatlığında kontrol edebilirsiniz. İlişkileri, kısıtlamaları ve ilişkilendirmeleri tam olarak belirleyebilirsiniz. Aynı anda özellik karakter sınırlarını ve veritabanı sütun boyutlarını ayarlayabilirsiniz. Hangi ilgili koleksiyonların istekli olarak yükleneceğini veya hiç serileştirilmeyeceğini belirtebilirsiniz. Kısacası, daha fazla şeyden siz sorumlusunuz, ancak uygulama tasarımınızı tamamen kontrol ediyorsunuz.

3) Veritabanı Sürümü Kontrolü

Bu büyük bir tane. Veritabanlarını sürümlemek zordur, ancak önce kod ve ilk kod geçişleri ile çok daha etkilidir. Veritabanı şemanız tam olarak kod modellerinize dayandığından, kaynak kodunuzu kontrol ederek sürümle veritabanınızı sürümlendirmeye yardımcı oluyorsunuz. Tohum sabit işletme verileri gibi şeyleri yapmanıza yardımcı olabilecek bağlam başlatmanızı kontrol etmek sizin sorumluluğunuzdadır. Önce kod taşımalarını oluşturmaktan da sorumlusunuz.

Taşıma işlemlerini ilk kez etkinleştirdiğinizde, bir yapılandırma sınıfı ve bir ilk taşıma oluşturulur. İlk taşıma, geçerli şemanız veya temel sürüm 1.0'ınızdır. Bu noktadan sonra, sürümlerin sıralanmasına yardımcı olmak için zaman damgası eklenmiş ve bir tanımlayıcı ile etiketlenmiş taşıma işlemleri ekleyeceksiniz. Paket yöneticisinden add-migration çağırdığınızda, hem UP () hem de DOWN () işlevinde kod modelinizde otomatik olarak değişen her şeyi içeren yeni bir migrasyon dosyası oluşturulur. YUKARI işlevi veritabanındaki değişiklikleri uygular, AŞAĞI işlevi geri almak istediğiniz olaydaki aynı değişiklikleri kaldırır. Dahası, bu görünüm dosyalarını yeni görünümler, dizinler, saklı yordamlar ve başka her şey gibi ek değişiklikler eklemek için düzenleyebilirsiniz. Veritabanı şemanız için gerçek bir sürüm sistemi haline gelecektir.

İlk kod yükselen yıldız gibi görünüyor. Ruby on Rails hızlı bir göz vardı ve onların standart kod ilk veritabanı geçişleri ile.

Bir MVC3 uygulaması oluşturuyorsanız, Code'un aşağıdaki avantajlara sahip olduğuna inanıyorum:

• Kolay özellik dekorasyonu - Alanları doğrulama, gereksinim vb. İle dekore edebilirsiniz. EF modellemesi ile oldukça garip
• Tuhaf modelleme hataları yok - EF modellemede genellikle ilişkilendirme özelliğini yeniden adlandırmaya çalıştığınızda, temel meta verileri eşleştirmesi gerekir - çok esnek değildir.
• Birleştirmek garip değil - Mercurial gibi kod sürümü kontrol araçlarını kullanırken, .edmx dosyalarını birleştirmek bir acıdır. Sen C # için kullanılan bir programcısın ve orada bir .edmx birleştiriyorsun. Önce kod ile öyle değil.
• Önce Kod ile kontrast yapın ve tüm gizli karmaşıklıklar ve uğraşmak bilmediğiniz tam bir kontrole sahipsiniz.
• Paket Yöneticisi komut satırı aracını kullanmanızı öneririm, iskele görünümlerine yeni bir denetleyici eklemek için grafik araçlarını bile kullanmayın.
• DB-Migrations - Daha sonra, Migrations'ı da etkinleştirebilirsiniz. Bu çok güçlü. Kodunuzda modelinizde değişiklikler yaparsınız ve ardından çerçeve şema değişikliklerini izleyebilir, böylece şema sürümleri otomatik olarak yükseltilir (ve gerekirse düşürülür). (Emin değilim, ama bu muhtemelen ilk önce modelle de çalışır)

Güncelleme

Soru ayrıca önce kodun EDMX modeli / db-first ile karşılaştırılmasını da ister. Önce kod, bu yaklaşımların her ikisi için de kullanılabilir:

• Model Ana : İlk Poços Kodlama (kavramsal model) daha sonra oluşturulması , veritabanı (geçişleri); VEYA
• Önce Veritabanı : Varolan bir veritabanı verildiğinde, eşleşecek POCO'ları manuel olarak kodlar. (Buradaki fark POCO'ların otomatik olarak oluşturulmamış olması, mevcut veritabanını verir). Ancak Entity Framework veya Entity Framework 5 - Varolan veritabanından POCO sınıfları nasıl oluşturulur? Kullanarak POCO sınıfları oluştur ve varolan bir veritabanı için eşlemeyi kullanarak otomatik olana yaklaşabilirsiniz .

Veritabanı yapılandırması üzerinde daha fazla esneklik ve kontrol sağlamak için önce EF veritabanını kullanıyorum.

Önce EF kodu ve modeli ilk başta havalı görünüyordu ve veritabanı bağımsızlığı sağlıyor, ancak bunu yaparken çok temel ve ortak veritabanı yapılandırma bilgilerini düşündüğümü belirtmenize izin vermiyor. Örneğin, tablo dizinleri, güvenlik meta verileri veya birden fazla sütun içeren bir birincil anahtarınız olabilir. Ben bu ve diğer ortak veritabanı özelliklerini kullanmak istiyorum bulmak ve bu nedenle doğrudan bazı veritabanı yapılandırması yapmak zorunda.

Ben ilk DB sırasında oluşturulan varsayılan POCO sınıfları çok temiz, ancak çok yararlı veri açıklama öznitelikleri veya saklı yordamlar eşleşmeleri eksikliği bulabilirsiniz. Bu sınırlamaların bazılarını aşmak için T4 şablonlarını kullandım. T4 şablonları özellikle kendi meta verileriniz ve kısmi sınıflarınızla birleştirildiğinde harika.

Model ilk önce çok fazla potansiyele sahip gibi görünüyor, ancak karmaşık veritabanı şeması yeniden düzenleme sırasında bana çok fazla hata veriyor. Emin değilim neden.

Büyük modellerle çalışmak SP1'den önce çok yavaştı (SP1'den sonra denemedim, ama şimdi bir çırpıda olduğu söyleniyor).

Hala ilk olarak tablolarımı tasarlıyorum, daha sonra şirket içi bir araç benim için POCO'ları üretiyor, bu yüzden her poco nesnesi için tekrarlayan görevler yapmanın yükünü alıyor.

Kaynak kontrol sistemlerini kullanırken, POCO'larınızın geçmişini kolayca takip edebilirsiniz, tasarımcı tarafından üretilen kodla o kadar kolay değildir.

POCO'm için bir tabanım var, bu da birçok şeyi oldukça kolaylaştırıyor.

Tüm tablolarım için görünümlerim var, her temel görünüm yabancı anahtarlarım için temel bilgiler getiriyor ve benim görüşüm POCO'lar yine oldukça kullanışlı olan POCO sınıflarımdan geliyor.

Ve sonunda tasarımcıları sevmiyorum.

Veritabanı ilk yaklaşım örneği:

Herhangi bir kod yazmadan: ASP.NET MVC / MVC3 Veritabanı Önce Yaklaşım / Önce Veritabanı

Bence bu diğer yaklaşımlardan daha iyi çünkü veri kaybı bu yaklaşımla daha az.

IMHO Ben tüm modellerin harika bir yer olduğunu düşünüyorum ama model ilk yaklaşım ile yaşadığım sorun birçok büyük işletmelerde DBA veritabanı kontrolleri ile veritabanı ilk yaklaşımları kullanmadan uygulama oluşturma esnekliği elde edemezsiniz. Birçok projede çalıştım ve konuşlandırmaya gelince tam kontrol istediler.

Kod İlk, Önce Model, Önce Veritabanı, tüm olası varyasyonları kabul ettiğim kadar, gerçek üretim ortamını göz önünde bulundurmalısınız. Yani sisteminiz birçok kullanıcı ve DBA'nın şovu çalıştıran büyük bir kullanıcı tabanı uygulaması olacaksa, ilk önce Veritabanı seçeneğini düşünebilirsiniz.

Önce kodun avantajlarından biri Git gibi bir sürüm kontrol sisteminde yaptığınız tüm değişiklikleri yedekleyebilmenizdir. Tüm tablolarınız ve ilişkileriniz esasen sadece sınıflarda saklandığından, zamanda geriye gidebilir ve veritabanınızın yapısının daha önce ne olduğunu görebilirsiniz.