Veritabanındaki alan modelleri sürdürülebilir bir çözüm olabilir mi?


13

Microsoft teknolojisine dayanan orta-küçük ölçekli bir şirket için veritabanı geliştirici olarak yeni bir işe başladım. En iyi uygulamalar, tasarım modelleri, testler ve proje yönetimi ile ilgili olarak okulda öğretilenlerden ne kadar uygulama saptığının farkına vardım.

Beni en çok rahatsız eden şey, ana veritabanı geliştiricimizin (bundan böyle "John" olarak anılacaktır) model şemasını veritabanında nasıl tuttuğudur! Bunu 3 "sihirli" masaya koyarak yaparız; biri veritabanı şemaları için, biri tablolar için ve biri sütunlar için.

" Tablolar " tablosuna bir kayıt eklemek , gerçek, karşılık gelen tablo oluşturur (bir veritabanı tetikleyicisi aracılığıyla). " Satırlar " tablosuna bir satır eklendiğinde, başvurulan tablo bu satırla güncellenir. Bunlar sırayla, ev yapımı C # programı tarafından ön uç geliştiriciler tarafından kontrolörler ve dışa doğru kullanılan C # modelleri oluşturmak için okunur.

Bunun dışında, çoğu geliştirme ASP.NET MVC çerçevesine göre yapılır .

Bu yaklaşımla birkaç kusur görüyorum:

  • ORM'yi sürdürmesi için ona ihtiyacımız var ve nadiren bunu yapmak için zamanı var (iş güvenliği iyidir!)
  • "Tablolar" ve "Satırlar" tablosunun tetikleyicileri hatalı. Tablo güncellemelerini veya Check-kısıtlamaları veya daha fazla "gelişmiş" özelliği desteklemezler. Onları kesinlikle geliştirebilsek de, bu yolun gidip gitmediğinden henüz emin değilim.
  • Programlı mantığın veritabanında tutulması garip ve kısıtlayıcıdır (modellerini C # ile genişletmek mümkün olsa da).
  • Onun C # Model-jeneratör (aralarında olduğum) 3 kişiden biri tarafından manuel olarak çalıştırılması gerekir ve henüz otomatik bir inşa sürecine dahil edilecek kadar olgun değildir.

Birkaç kişi Entity Framework gibi gerçek ve test edilmiş bir üründe aşamalandırmayı önerdi , ancak iş mantığını kod katmanında tutmanın yalnızca küçük ölçekli uygulamalar ve yeni başlayanlar için önyükleme projeleri için uygun olduğunu iddia ederek bunu reddetti.

Bu yazı, tartışmalı bir tartışma gibi görünebilecek bir şeye yöneliyor, ancak niyetim bu değil. Sadece mimari yaklaşımımızla ilgili biraz açıklama yapmak istiyorum.

Alan modellerinin veritabanında tutulması, büyümekte olan bir şirket için sürdürülebilir bir çözüm olabilir mi?


Etki alanı modelleri, etki alanı güdümlü tasarıma çok yakından bağlıdır. Etki alanı güdümlü tasarımın tüm noktası, verinin (yani veritabanı) uygulamanın çekirdeği olduğu veri güdümlü tasarıma sahip olmamalıdır. Bahsedilen yaklaşım ve alan modelleri gerçekten bir arada değildir. Etki alanı odaklı tasarım uygulamalarını takip ederek geliştirirken, verilerin nereden geldiğini umursamazsınız, sadece onu kullanır ve iş katmanınızda mantık gerçekleştirirsiniz.
Andy

"Programatik mantığı veritabanında tutarak" ne demek istediğimi biraz açık değilim. Bunu açıklığa kavuşturabilir misiniz?
Robert Harvey

Koddaki iş mantığı tam olarak doğru yoldur. Db aptal bir veri deposu olmalı, başka bir şey değil.
Andy

@ Sanırım bu duruma bağlı. DBA takımın merkezi olabilir ve tüm iş mantığını veritabanında tutar, bu da daha sonra aptalca saklanan procs çağrıları ile sorgulanır, POCO'lara veri çıkarır. hepsi DB'de değilse.
Vladislav Rastrusny

@VladislavRastrusny Sebep ne olursa olsun, iş mantığını db'de tutmak son derece zayıf bir tasarımdır.
Andy

Yanıtlar:


16

Bir İç Platformu tarif ediyorsunuz .

İç platformlarla ilgili sorun, onlarca yıllık evrim ve çabalar boyunca honlanmış ve mükemmelleştirilmiş, ancak onu zayıf bir şekilde yeniden icat eden bir platform veya teknolojinin (bu durumda ilişkisel bir veritabanı) tüm mekanizmalarını yeniden keşfetmenizdir. Daha geleneksel bir tasarım seçenler için mevcut olan tüm optimizasyonları atlıyorsunuz ve gelecekteki karmaşıklık ve zorluk için başlangıç ​​sadeliği ve zarafeti ile ticaret yapıyorsunuz.

Dedi ki, bu sürecin son ürünü ise gerçek tabloları ve gerçek modelleme sınıfları gerçek iş alanı nesneleri, ben ayrı araçlar immaturitesine, bu yaklaşımda çok zarar görmüyorum. Stack Exchange aslında kendi, kendi yetiştirdiği ORM'yi kullanıyor ve bu onlar için işe yaramış gibi görünüyor. Bu tür "yazlık" yaklaşımların işe yarayabileceğini biliyorum.

"İlk tablo" yaklaşımını alan çoğu ORM sınıfları oluşturmak için veritabanındaki tablo yapısına bakmak unutmayın. Arkadaşınız yarattığı "tablo" ve "satır" tabloları olduğu sadece meta olduğunu zaten var en modern ilişkisel veritabanı sistemlerinin sistem tablolarında.

İleri Okuma
"Vizyon" projesi, iç platform etkisi hakkında uyarıcı bir hikaye
(Önsözü atlayabilir ve "Vizyon Tanıtımı" alt başlığında okumaya başlayabilirsiniz)


2
İlginç bir şekilde, kesinlikle anolojiler çizebilirim. Hala yeniyim ve şimdilik izleyici olarak kalacağım, ama kesinlikle mercek altında tutacağım. İyi bir yanıt için teşekkürler!
krystah
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.