Saklı yordamlar üç aşamalı ayrımı ihlal ediyor mu?

Bazı meslektaşlarım, veritabanındaki saklı yordamlarda iş mantığına sahip olmanın, üç katmanlı ayırma mimarisini ihlal ettiğini, çünkü veritabanının veri katmanına ait olduğunu ve saklı yordamların da iş mantığı olduğunu söylediler.

Bence dünya, saklı yordamlar olmadan çok acımasız bir yer olurdu.

Gerçekten üç aşamalı ayrılığı ihlal ediyorlar mı?

Meslektaşlarınız mimarlığı uygulamayla birleştiriyor.

Çok katmanlı bir uygulamanın arkasındaki fikir basitçe belirli işlem türlerini (depolama, iş mantığı, sunum) içeren ve iyi tanımlanmış arayüzleri kullanarak birbirleriyle iletişim kuran parçalara bölünmesidir. Nesne yönelimli programlamaya benzeyen şeyleri nesne yönelimli olmayan dillerde başarılı bir şekilde yapabilmek gibi, aynı şeyi veritabanı sunucusu gibi bir ortamda birden çok katmanla da yapmak mümkündür. Bunlardan birini başarılı bir şekilde ortak yapmak, bakım, disiplin ve ilgili uzlaşmaların anlaşılması için bir ihtiyaçtır.

İki aşamanın veritabanına uygulandığı üç katmanlı bir uygulamaya bakalım:

• Veri katman: dört standart tablo işlemleri kullanılarak erişilir veritabanı tablolarının oluşur ( INSERT, UPDATE, DELETEve SELECT).
• Mantıksal Katman: Yalnızca iş mantığını uygulayan ve yalnızca yukarıda belirtilen yöntemleri kullanarak veri katmanına erişen depolanmış prosedürlerden oluşur.
• Sunum Katmanı: Yalnızca saklı yordam çağrıları yaparak mantık katmanına erişen kod çalıştıran bir web sunucusundan oluşur.

Bu mükemmel bir şekilde kabul edilebilir bir model, ancak bazı değişimlerle birlikte geliyor. İş mantığı, veri katmanına hızlı ve kolay erişilmesini sağlayacak ve veritabanının dışındaki bir mantık katmanı tarafından "zor yoldan" yapılması gereken şeylerin yapılmasına izin verecek şekilde uygulanmaktadır. Vazgeçtiğiniz şey, bir başka teknolojiye ve kaygısız uygulamaya kolayca katılabilme yeteneğidir (yani, katmanların veritabanında bulunan tesisleri ancak tanımlanmış arayüzlerinin dışında kullanmamalarına dikkat etmeniz gerekir). .

Belirli bir durumda bu tür bir şey ve getirdiği travmalar kabul edilebilir olup olmadığı, sizin ve meslektaşlarınızın kararınızı kullanarak belirlemeniz gereken bir şeydir.

Saklı yordamlar, iş mantığını RDBMS katmanına getirerek üç aşamalı ayrım ihlalini kodlamanıza izin verecek kadar güçlüdür. Ancak, bu sizin kararınızdır, saklı işlemlerin doğal bir kusuru değildir. SP'lerinizi veri katmanınızın gereksinimlerini karşılamakla sınırlandırırken, uygulama mantığınızı mimarinizin uygulama katmanında tutar.

İş mantığını içermek için saklı yordamlara (özellikle bir grup tetikleyici) ihtiyaç duyduğunuzda, ayırma kuralının nadir fakat önemli bir istisnası vardır. Bu, uygulamanızın milyonlarca satıra dokunan çok sayıda anında veri toplaması oluşturması gerektiğinde gerçekleşir. Bu gibi durumlarda, iş katmanının kullanımı için önceden toplanmış verileri korumak için tetikleyiciler ayarlanabilir. Bu, yalnızca toplamadan önce uygulamanızın kabul edilemez derecede yavaş olacağı durumlarda yapılmalıdır.

Atwood’un 2004’teki tavsiyesi bugün hala doğru, sadece biz de ORM’nin faydası var.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Saklı yordamlar veritabanı derleme dili olarak düşünülmelidir: yalnızca en kritik performans durumlarında kullanmak için. Saklı Prosedürlere başvurmadan sağlam, yüksek performanslı bir veri erişim katmanı tasarlamanın birçok yolu vardır; parametreli hale getirilmiş SQL ve tek bir uyumlu geliştirme ortamı ile bağlı kalırsanız, birçok avantaj elde edersiniz.

Kısa Özet: Bu, gerçekten saklı yordamları ve iş gereksinimlerini kullanımınıza bağlıdır.

Üç katmanlı bir mimari kullanan birkaç proje vardır ve iş gereksinimlerinin niteliğine bağlı olarak bazı işlemleri bir veri katmanına kaydırmanız gerekebilir .

Terminoloji hakkında konuşmak, genel olarak şu sözler şöyle tanımlanır:

• Sunum katmanı veya kullanıcı hizmetleri katmanı - kullanıcıya uygulamaya erişim izni verir.
• Orta seviye veya işletme hizmetleri katmanı - işletme ve veri kurallarından oluşur.
• Veri katmanı veya veri hizmetleri katmanı - genellikle bir veritabanında veya kalıcı depolamada saklanan kalıcı verilerle etkileşime girer.

Genellikle verilen mimari için, orta seviye veya iş hizmetleri katmanı, iş ve veri kurallarından oluşur. Bununla birlikte, bazen, veri kümesinde saklanan prosedürler kümesinde yapılması gereken ağır set temel işlemlerinin ve / veya veri kurallarının kaydırılması büyük fark yaratır .

Üç katmanlı tasarımların faydaları:

Bir uygulamanın yaşam döngüsü boyunca, üç aşamalı yaklaşım yeniden kullanılabilirlik, esneklik, yönetilebilirlik, bakım yapılabilirlik ve ölçeklenebilirlik gibi faydalar sağlar. Oluşturduğunuz bileşenleri ve hizmetleri paylaşabilir ve yeniden kullanabilir ve gerektiğinde bunları bir bilgisayar ağında dağıtabilirsiniz. Büyük ve karmaşık projeleri daha basit projelere bölebilir ve farklı programcılara veya programlama ekiplerine atayabilirsiniz. Ayrıca, değişiklikleri izlemeye yardımcı olmak için bileşenleri ve hizmetleri bir sunucuya dağıtabilirsiniz ve bunları uygulamanın kullanıcı tabanı, veri ve işlem hacmi arttıkça yeniden dağıtabilirsiniz.

Bu nedenle, aslında kendi içinde dengeleri olan bir vaka temelli yaklaşımdır. Ancak, Üç Katmanlı Mimari Modelin Microsoft tasarım kuralları, iş mantığınızı orta katmanda tutmanızı önerir .

Katman aslında farklı makine, katman ise farklı mantıksal ayrım anlamına gelir. Saklı yordamlarla aynı katmandaki veri katmanına ve (en azından bir kısmına) iş mantığı katmanına sahip olursunuz. İş mantığını saklı yordamlara sokmak 3 yorgun mimariyi ihlal ediyor, ancak 3 katmanlı mimariyi ihlal edip etmediğini sorgulamakta; Kesin olan bir şey, kesinlikle endişelerin ayrılmasının iyi bir örneği olmadığıdır.

Katman, yazılım çözümünüzü oluşturan öğeler için mantıksal bir yapılandırma mekanizmasıdır; seviye, sistem altyapısı için fiziksel bir yapılanma mekanizmasıdır. ( Referans )

Kanımca veritabanında iş mantığı oluşturmanın iki ana sorunu var:

1. Kod ve kütüphaneler: SQL, PL / SQL, TSQL vb. Programlarda C #, Java vb. Programlarda programlayabileceğiniz daha az programcı bulacaksınız.

2. Yatay ölçeklenebilirlik: Sisteminizi ölçeklendirmenin tek yolu, veritabanının bulunduğu güçlü sunucuyu daha güçlü olana göre değiştirmektir (oldukça pahalı olan (64 GB RAM'e sahip bir sunucu)); ilişkisel veritabanları yatay olarak çok kötü ölçeklendirir ve hatta daha büyük masraflarla. OO yerleşik sunucusundaki iş mantığıyla, sunucuyu birçok düğüme yerleştirerek yatay olarak oldukça iyi ölçeklendirebilirsiniz (Java'da birçok uygulama sunucusu bunu destekler).

Bu tartışmayı bazı zamanlar ofisimizde yaptık, Veri Tabanı Geliştirmeyi destekliyordum

1. Oracle Database kullanıyorsanız, PL / SQL'i mümkün olduğunca kullanmalısınız, çünkü yatırım yapan şirketler bundan sonra 10 yıl boyunca bile olsa kehanete sadık kalacaklar. Dün yapılan uygulamalarda Oracle Forms kullanıyorsanız, bugün .net Web formları, sonra MVC, sonra yarın angularjs kullanacak ve sadece apislere ihtiyacınız olacak. Eğer maksimum mantık veri tabanında bulunuyorsa, kolayca yeni ön uç teknolojilere geçebilirsiniz.
2. Veri tabanı geliştirme çok hızlı ve çok verimli bir performans. Sadece sana bir şans vermek için. Projemizde 7 uygulama geliştiricisi ve bir veritabanı geliştiricisi vardı ve mantığın% 80'i veritabanındaydı.
3. Oracle kullanıyorsanız, veritabanı işlemlerinizi doğrudan Res full Api'ye dönüştürmek için yardımcı programları kullanabilirsiniz.

Uygulama geliştiricilerinin, iş mantığının veritabanından bağımsız olması gerektiği konusundaki en güçlü argümanı, veritabanını kolayca değiştirebilmenizdir. Bir firmanın kehanet kullanıyor olması durumunda neden eski teknolojiye geçeceklerini, bunun yerine uygulama mantığını eski haline getirme şansının daha fazla olacağını düşünüyorum. Sorun çoğunlukla veritabanı kaynaklarının yeni yeteneklerinin bulunmaması, çoğunlukla erkekler başlarsa mysql veya sqlserver kullandıkları basit web siteleri olacaktır. Bu adamlar daha sonra kıdemli liderler haline gelir ve uygulama katmanıyla duygusal bağ kurarlar :) hatta anlamak veya tartışmak istemezler.