Bir geliştirici neden bir veritabanına doğrudan bağlantı yerine web hizmetlerini kullanmalıdır? [kapalı]

Doğrudan veritabanına bağlanmak yerine web hizmeti aracılığıyla uzak veritabanlarına bağlanmamız gerektiğine ilişkin nedenlerin "ilk on" listesini arıyorum. Bu şu anda dahili bir tartışma ve ben web servis yanlısı ama tartışmayı kaybediyorum. WCF / web hizmetleri hakkında temel bilgilere sahibim, başka kimse yok. İlerlemek istediğimizi yapabiliriz ama şimdi seçtiğimiz şeye bağlı kalmalıyız.

İşte bulduğum şey. Başka var mı?

1. WCF web hizmetleri, doğru yapılandırılırsa daha güvenli olabilir.
2. DB'deki değişikliklerin yalnızca hizmet düzeyinde (yapılandırma dosyası veya yeniden derleme hizmeti) yapılması gerekir.
3. Kurulumdan ve barındırıldıktan sonra web hizmetlerinin tüketilmesi daha kolaydır.

1. Güvenlik. Web sunucusu / uygulama kullanıcısı dışında hiç kimseye DB erişimi vermiyorsunuz.

   Tonlarca kullanıcınız olduğunda bu çok önemlidir. DB tarafında kullanıcı / rol bakımının acısını ortadan kaldırırsınız.

2. DB yük azaltma. Web hizmeti, DB'den aldığı verileri önbelleğe alabilir.

3. Veritabanı bağlantı havuzu (hat / ipucu @Dogs).

   Bir web hizmeti, kalıcı olarak açılan küçük bir DB bağlantı havuzunu kullanabilir. Yardımlar çeşitli şekillerde:

   • DB bağlantı havuzu, veritabanı sunucusu tarafında sınırlıdır.

   • yeni bir DB bağlantısı açmak ÇOK maliyetlidir (özellikle veritabanı sunucusuna).

4. Hata toleransı yeteneği - hizmet, hizmet tüketicileri tarafından yerine getirme ayrıntılarına sahip olmadan birincil / DR veri kaynakları arasında geçiş yapabilir.

5. Ölçeklenebilirlik - hizmet, kaynak toplamanın ayrıntılarının hizmet tüketicileri tarafından uygulanmasına gerek kalmadan istekleri birkaç paralel veri kaynağı arasında dağıtabilir.

6. Kapsülleme. Hizmet kullanıcılarını etkilemeden temeldeki DB uygulamasını değiştirebilirsiniz.

7. Veri zenginleştirme (bu, müşteri özelleştirmesinden yerelleştirmeye ve içselleştirmeye kadar her şeyi içerir). Temelde bunlardan herhangi biri yararlı olabilir, ancak bunlardan herhangi biri veritabanı üzerinde büyük bir yük oluşturur ve genellikle bir DB içinde uygulanması çok zordur.

8. Sizin için geçerli olabilir veya olmayabilir - bazı mimari kararlar DB erişimi dostu değildir. Örneğin, Unix üzerinde çalışan Java Sunucuları bir veritabanına kolay erişime sahipken, Windows PC üzerinde çalışan bir java istemcisi veritabanından haberdar değildir ve siz de olmasını istemezsiniz.

9. Taşınabilirlik. Müşterilerinizin hepsi aynı platformda / mimaride / dilde olmayabilir. Bunların her birinde iyi bir veri erişim katmanı oluşturmak, bir web hizmeti için bir tüketici katmanı oluşturmaktan daha zordur (çünkü yukarıda belirtilen yük devretmeleri / vb ... gibi sorunları hesaba katmalıdır).

10. Performans ayarı. Alternatifin, istemcilerin kendi sorgularını çalıştırması (ve önceden hazırlanmış depolanmış yordamları değil) olduğunu varsayarsak, en uygun sorguları kullanmaya başlayacaklarından% 100 emin olabilirsiniz. Ayrıca, web hizmeti izin verilen sorgular kümesini sınırlarsa, veritabanı ayarlamanıza önemli ölçüde yardımcı olabilir. Bu mantığın, web hizmetlerine özgü değil, depolanan yordamlar için de aynı ölçüde geçerli olduğunu eklemeliyim.

Bu sayfada iyi bir liste de bulunabilir : 'Kapsüllenmiş Veritabanı Erişimi: Çevik Bir "En İyi" Uygulama'

Açık konuşmak gerekirse, bu sorunlardan bazıları TÜM durumlar için geçerli olmayabilir. Bazı insanlar taşınabilirliği umursamıyor. Bazı kişilerin DB güvenliği konusunda endişelenmesine gerek yoktur. Bazı kişilerin DB ölçeklenebilirliği konusunda endişelenmesine gerek yoktur.

Kanımca, veritabanınızı otomatik olarak bir web hizmeti olarak ifşa etmemelisiniz. Verilerinizi açığa çıkarmak için bir hizmete ihtiyacınız olduğu ortaya çıkarsa, bir tane yazın, ancak tüm veritabanı erişimi web hizmetleri aracılığıyla yapılmamalıdır.

1. Bir veritabanı bağlantısının güvenli olmaması için hiçbir neden yoktur
2. Veritabanını bir veri erişim katmanında (muhtemelen Entity Framework) kapsülleyebilirsiniz.
3. Web hizmetlerini kullanmak, iyi yazılmış bir veri erişim katmanından daha kolay değildir.

• Web Hizmetleri, harici sistemler ve uygulamanın verileri arasında izin verilen etkileşimleri tanımlayan bir API oluşturur.
• Web Servisleri, veritabanını harici etkileşimlerden ayırır ve veri katmanının bu dış etkilerden bağımsız olarak yönetilmesini sağlar.
• Yalnızca Web Hizmetleri tarafından erişime izin verilmesi, uygulama mantığının yürütme şansı elde etmesini sağlayarak veri bütünlüğünü korur.
• Web Servisleri, kullanıcı adı ve şifre / tablo düzeyinde ayrıcalıklar gerektiren bir veritabanının aksine, en uygun kimlik doğrulama / yetkilendirme önlemlerinin alınmasına izin verir.
• Web Hizmetleri, kullanılacak otomatik hizmet keşfi ve yapılandırması için bir fırsat sağlar.
• Web Hizmetleri trafiği, güvenli olmayan ağlar üzerinden geçiş için şifrelenebilir. Bunu sağlayan herhangi bir doğrudan DB bağlantı çözümü bilmiyor musunuz ...?

Bu noktaların çoğu, özellikle Web Hizmetleri için değil, herhangi bir resmi API için geçerlidir.

Aramaları depolanmış yordamlara basitçe saran bir web hizmeti yazmak, iyi bir DAL tasarlamak için yanlış bir yaklaşım gibi görünüyor. Büyük olasılıkla, depolanan prosedürleriniz eski bir istemci-sunucu sistemlerinden kalan eski kodlardır, yani iş kuralları SP'lerde gömülüdür. Eğer durum buysa, gerçekten bir dişi domuzun kulağından ipek bir çanta yaratmaya çalışıyorsunuz.

Ayrıca, bu "domuz" ile çıkmaya 'zorlanan' web uygulamalarına bir performans vuruşu ekleyen bir SOAP mesaj protokol katmanı eklemeniz. Şu anda yeni MVC-4 uygulamamıza böyle bir DAL kullanma talimatı verilen bir proje üzerinde çalışıyorum. Bu tür değişiklikleri gerektiren yeni bir kullanıcı öyküsü ortaya çıktığında, hem WebMethod imzasını hem de SP imzasını değiştirme yüküne sahibiz; bu bizim için her bir sprint. Böyle bir geçiş yaklaşımının özünde iki adet sıkı bir şekilde bağlanmış katman vardır.

1) Veritabanını sürdürme sıkıntısı geliştiriciler tarafından azaltılır, böylece yalnızca geliştirmeye odaklanabilirler.

2) Web hizmeti, çok kolay ve etkili bir yöntemle farklı platformların (windows, ios, android vb. İşletim sistemleri) iletişimini destekler. Örneğin, android uygulama ve ios uygulamasının java tabanlı bir web sitesiyle iletişim kurmak istediği bir durumu göz önünde bulundurun, bu nedenle üç şeyin tümünün iletişimi için webservice, üç farklı veritabanını sürdürmek yerine en iyi çözümdür.

Genel olarak

1. Web Hizmeti düzeyi, birden çok uygulama için ortak veri taleplerinin yeniden kullanımını destekler
2. Web Hizmeti, uygulama düzeyi geliştirmeden kaynaklanan birçok sorunu saptıran sürüm yönetimi ile kurulabilir. Örneğin, mevcut uygulama olan bir projede yeniysem, uygulamamı mevcut veritabanı kaynaklarını kullanacak şekilde yapılandırmak için iyi bir model olarak kullanırım.
3. Web Hizmeti, basit bir URI kullanarak istekleri göndermek ve yanıt sonuçlarını JSON gibi ortak bir formatta geri almak için esnek seçeneklere izin verecek şekilde gelişmiştir; bu, istemci uygulamalarının güvenilir tek tip arayüzleri teşvik eden daha yaygın bir standart kullanılarak geliştirilebileceği anlamına gelir.

Sadece ASP.NET Web Api ile ilgileniyorum ve önce veri hizmetlerini yapmayı planlıyorum.

Son zamanlarda, varlık çerçevesinin kullanımıyla .NET MVC web uygulamalarına odaklanıyorum.

1. Zaten MVC kullanıyorsanız, Web Api ayrıca MVC'yi Api denetleyicisiyle kullanır, böylece hizmetleri oluşturmak için öğrenme eğrisi oldukça ağrısızdır.

Başlangıçta Oracle depolanan prosedürlerine dayalı olarak oluşturduğum bir MVC web uygulamasıyla kısa süre önce kendimi sinir bozucu bir durumda buldum. Oracle 9 veya daha önceki sürüm gibi orijinal sürüm, Visual Studio 2012 ile daha modern bir bağlantı fabrikası yaklaşımını zorlayarak web yapılandırma bağlantılarına ve TNS adlarına dayalı olarak kullanılacak doğru dll dosyalarını bularak daha modern bir bağlantı fabrikası yaklaşımını ortaya koydu.

Veritabanına bağlanma girişimleri "artık desteklenmiyor" hata mesajlarıyla başarısız oldu. Merak ettiğim için Oracle 12c'yi indirdim ve TNS isimlerim ve yük derleme dll ile güzelce çalışan bazı uygulama seviyesi bağlantıları yaptım ve Oracle ile sorunsuz çalışabildim.

Eski Oracle sürümüne bağlantılarla çalışan bazı web servisleri inşa edildi. Bunlar, benim hayal kırıklığıma rağmen, seçilen tablolarla özel olarak eşleştirilen yöntemlerle oluşturuldu. Kendi yazmam gerekirdi.

Oracle veritabanlarının bakımından sorumlu olan gruba, istemci arayüzünü ve iş mantığı katmanlarını soyutlamak için kullandığım eski prosedürlerin yerine yeni depolanmış prosedürler yazacakları söylendi.

Bu yüzden ilk düşüncelerim, aşağı açılır listeyi doldurma veya kurumsal çaptaki verilerle otomatik tamamlama gibi tüm ortak veri taleplerinin, Oracle saklı prosedürlerini çağıran veri hizmetleri aracılığıyla yapılmasıydı. Neden bu işlemi her uygulama üzerinde tekrarlayıp her geliştiricinin yapılandırma ve sürüm / yük derlemesi, TNS sorunları ile uğraşmasını sağlayın?

yani....

1. SQL Server veri kullanımı için genellikle EF kullanan bir .NET MVC uygulamasında Oracle saklı yordamlarının kullanılması gibi birden çok veritabanı sunucusu sorunu için, neden bu baş ağrılarını bu yapılandırma sorunlarının izole edilebileceği Web Api hizmet yöntemlerine itmeyin.
2. Yine istemci arabirimi, SQL Server veri istekleri yapmak için Web Api kullanarak zaten kullanmakta olduğunuz JavaScript, JQuery ve JSON kullanılarak yapılabilir.

Ben bir Uygulama Geliştiricisi / Analistiyim ve bir DBA değilim, bu yüzden bakış açım, veritabanı araçları gelişirken uygulamaları sürekli olarak değiştirmek zorunda kalmanın hiç bitmeyen hayal kırıklığı deneyiminden kaynaklanıyor.