Veritabanım bana ait!
Veritabanlarının birlikte kullanımı makul görünüyor – sonuçta veriler yeni yağdır. Bununla birlikte, bu, modern yazılım – modülerleştirmenin geliştirilmesi için önemli bir temelle çelişmektedir.
Nesne yönelimli sınıfları bir sistem için tek modül olarak alırsanız, sorunlar hızla ortaya çıkar. Bir sistemin bir milyon satır kod (kod satırları, LOC) olduğunu varsayalım. 1000 LOC'a sahip bir sınıf oldukça büyük olurdu, ancak o zaman bile sistemin 1000 modülü olacaktır. Bu nedenle sınıflardan daha kaba granüler modüllere ihtiyaç vardır. Mikro hizmetler böylesine brüt granüler modüller olabilir. Veya bazı sınıflar bir formda özetlenir. Böyle bir modülün arayüzü, iç mekanların gizlenmesi için tek bir cephe sınıfı oluşturabilir. Kaba granüler modülleri, örneğin kitaplıklar veya kendi programlama dillerinin modülleri kavramları ile uygulamanın birçok yolu vardır.
David Parnas “modül” terimini tanımlamada önemli bir rol oynadı. Bu bağlamda önemli bir belgedir “Tasarım metodolojisinin bilgilerinin dağılımının yönleri” 1971'den beri iyi bir geliştiricinin, kodunun uygulanması sırasında kendisi için mevcut bir formda tüm bilgileri kullanacağını iddia etti. Bu nedenle kodu, diğer modüllerin nasıl uygulandığına dair hipotezleri etkiler. Bu hipotezler kodu ne kadar etkilerse, kullanılan modülleri değiştirmek o kadar zor olur. Sonuçta, tüm koşulları tatmin etmeye devam etmelisiniz. Modülleri değiştirilebilir tutmak için, olası modüller hakkında daha az bilgi sağlamak gerekir, böylece kullanıldığında sadece birkaç hipotez alınabilir. Biri “bilginin saklanmasından” bahsediyor: bilgi için saklanma yeri.
Bilgi gizleme
Belge belgeyi yazdığında, bilgiler esas olarak dokümantasyonda yayıldı. Belge ayrıca bazı kararların sadece bir formda tanınabilir olması gerektiğini iddia ediyor. Bu, bir form verileri sakladığı için ilgili formdaki yolu içerir.
Bugün bilgiyi gizlemek, nesneler odaklı sınıfların onları dışarıda açmamasının nedenidir, ancak gizlenir. Bir sınıf, veri arşivinin uygulanmasını değiştirebilir, çünkü bu konuda hiçbir bilgi harici olarak nüfuz eder.
Modüllerin ortak bir veritabanı yok!
Bu kaba granüler modüller için gizli olan bilgiler, uygulama değişkenlerinin gizlendiği anlamına gelemez. Sonuçta, farklı sınıflardan oluşurlar. Bu nedenle sınıflarla sınırlı olan bilginin saklanma yeri bu bağlamda mantıklı değildir.
Kaba granüler modüller genellikle veritabanındaki verileri arşittir. Bu nedenle, mikro hizmetler gibi kaba granüler modüllerin veritabanı şemasına sahip olması gerektiğini gizleyen bilgilerden türetilebilir, aksi takdirde diğer modüller veritabanı şemasına doğrudan erişir ve bu nedenle veritabanındaki verilerin arşivlenmesi yoluyla hipotezlenir. Bu, veri modellemesinin değiştirilmesini önemli ölçüde sınırlar. Sınıflar uygulama değişkenlerini ortaya çıkarmaya yetkili olmadığından, kaba granüler modüller veritabanı kalıplarını görüntüleymemelidir. Görünümler gibi kukla veritabanlarının mekanizmaları genellikle yakın bir bağlantıya ve aynı sorunlara yol açar.
Ne yazık ki, bu kural genellikle memnun değildir. Bu, büyük veritabanı şemalarına yol açar, çünkü birkaç modülün gereksinimleri karşılanmalıdır. Buna ek olarak, çok fazla modül etkilendiğinden desenler genellikle değişmemiştir. Deneyimlerime göre, veritabanı şemalarının çok karmaşık olduğu ve sistemde değişiklikler yapmanın yanı sıra imkansız olgusal veritabanında çok fazla sistem var – çoğu zaman kimse sistemi artık anlamıyor.
Modüllerin tanımından, verilerin modüllerde depolanmasının gizlenmesi gerektiğini gerçekten görebilir. Bu seviyede gizlenen bilgileri uygulamak ve bu nedenle değişikliklere ve anlaşılabilir veri modellerine ulaşmak, karmaşık projelerin gelişimini önemli ölçüde basitleştirmek için önemli bir potansiyele sahiptir.
TL; Dr.
Sistemler, ayrı veritabanı modellerine sahip kaba granüler modüllere ayrılmalıdır. Veritabanı şemalarının ortak kullanımı, birçok sistemin ve birçok veritabanı kalıbının değişebilirliğinin olmamasının ana nedenidir.
Not: Blog yazısının ilk versiyonunda tartışma için meslektaşları Innoq Jan Friderici, Stefan Tilkov ve Michael Vitz'e teşekkürler!
()