Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5
win32-rest-service-json-database ilşkisi
#1
@Fesih ARSLAN Hocam 
Seminerinizi severek izledim tesekkür ederim elinize saglık.
Klasik yöntemlere alışık oldugum için (birçok arkadaşıda oyle oldugunu dusunuyorum) yeni ve hizli mimarileri ogrenmeye çalısıyorum.
Soyle bir sorum olacak. Win32 ortami icin konusursak mssql veritaaninda islem yapmak icin forma adosp,adotable vs atip direk islem yapiyoruz.
Anlattiginiz yeni mimaride kabaca yol haritasi nasil isliyor. Soylemi; 
Bir rest server var . Bu rest server icin bir service yazacagiz. Sonra service ile veritanindan bilgi alip json olarak win32 uygulamasina gonderecgiz. Bu iletisim win32 tarafinda hangi nesne ile karsilanacak yada islem komutarimiz ne ile gonderilecek.
Kusura bakmayin karisik olduysa. mimariyi anlamaya calisiyorum
Cevapla
#2
Merhaba,
Rica ederim. İlerleyen aşamalarda daha iyi olacağına eminim.
Eğitimde yeterince değindim. Fakat bir senaryo üzerinden gitmediğim için anlaşılmamış olabilir.
Burada o açığı tamamlamaya çalışayım.

Öncelikle önümüze bir proje isteği geliyor. 
* ABC projesi yapılacak.

* Kağıt üzerinde (daha sonra mutlaka dijital ortama taşınmalı) veya dijital ortamda hemen bir gereksinim analizi (2. eğitimde detaylı olarak nasıl yapılacağını anlatmıştım) yaparız.
* Analiz sonucunda donanımsal ve yazılımsal ihtiyaçlar ortaya çıkacaktır. 
  • Proje hangi işletim sistemi üzerinde çalışacak? 
  • Hangi veri tabanı kullanılacak?
  • Sunucu lokalde mi, 
  • iç network'te mi, 
  • dışarıya (internet ortamına) açık mı, 
  • dışarıya açıksa başka veri kaynaklarına (WS veya REST API)  ihtiyaç olacak mı?
Bu soruların cevapları uygulamanın nasıl bir uygulama olacağını belirleyecektir. 
Örneğin, Windows işletim sistemi - Masaüstü uygulama - Lokal PC de doğrudan bir veri bağlantısının hiç bir sakıncası yok. Hatta olması gereken yöntemdir.

Diğer durumları şematize ederek açıklayayım.

Aşağıdaki sistemde uygulama, dışarıya açılmayan lokal bir pc üzerinde çalışıyorsa; uygulama doğrudan veri tabanına bağlanabilir. 
Uygulama ile veri tabanı arasına herhangi katman eklemeye gerek yoktur.
 
   

Aşağıdaki ikinci durumda, dışarıya açılmayan bir iç network üzerinde uygulama çalışacaksa; herhangi bir client-server mimari kullanılabilir. 
Neden bu sistemde client-server kullanılabilir? 
Bir veri tabanına eş zamanlı farklı PC'lerden bağlantı isteklerinin kontrol altına alınması için gereklidir. 
Kullanıcı sayısının az olduğu küçük network'ler hariç tutulabilir.
Fakat büyük iç network'lerde bir güvenlik protokolü ve veri katmanına ihtiyaç olacaktır.   

   


Aşağıdaki üçüncü durumda, dışarıya açılan tek bir veri sistemi için uygulama yazılıyorsa; eş zamanlı bağlantı sayısına bağlı olarak client-server uygulama olmalıdır.
Tek tip bir uygulama (cross değil) ve tek bir veri tabanı için bir web servis veya REST API geliştirmenin çok da bir anlamı yok.
Fakat bu sistemde veri tabanınız ilerleyen süreçlerde farklı bir uygulama (cross---> web, mobil, masa üstü bir CRM, ERP veya Muhasebe) tarafından kullanılacak ise WS ve REST kaçınılmaz olacaktır.
Yabancı bir uygulama ve yabancı bir platform için bir kaç katmana ihtiyaç var.
Veri tabanı katmanı, iş katmanı ve güvenlik katmanı bunlardan en temel olanıdır.
Özel verilerin dışarı açılmasından dolayı bu mimariye (WS, REST) ihtiyaç vardır.   

   

Aşağıdaki dördüncü durumda, dışarıya açılan birden fazla veri sistemi için uygulama yazılıyorsa; SOA kaçınılmazdır. 
Uygulamalar sizin açmış olduğunuz web servisler veya REST servislerine bağlanacak. Bunların mutlaka bir SOA mimarisi ekseninde modellenmesi ve sunulması gerekmektedir. 
 

   

Son olarak performans konusuna değineyim;
Yukarıda anlattığım dört durumda performans açısından kendi içinde değerlendirilmelidir. 
  • Yani birinci durum için araya bir katman veya kural koymak işi yavaşlatabilir. Doğrudan bağlantı daha idealdir.
  • İkinci durumda en büyük kriter eş zamanlı kullanıcı sayısıdır. Burada doğrudan bağlantılar işi daha da yavaşlatacaktır. 
    Sunucu-istemci mimarisinde performans daha yönetilebilir olur. 
    Örneğin eş zamanlı 100 commit olayında, ClientDataset veya bir MemTable uygun bir zamanı bekler ve network müsait olduğunda işi gerçekleştirir. Kullanıcıyı beklemeye almadığı için iş kaybı olmaz. Doğrudan bağlantıda istek sonuçlandırılıncaya kadar uygulama kilitlenir.
  • Üçüncü durumda artık veri dış ortama açılıyor. Performansı etkileyen bir çok unsur vardır. Bunların en başında veri tabanı ve sunucu uygulamasının bulunduğu sunucunun donanımsal özellikleri, internet hızınız, veri tabanından sorgu yöntemi, sunucu istemci arasındaki iletişim protokolleri ve istek-cevapların veri formatı önem kazanmaktadır. Burada ws ve REST olması durumunda; sunucunuz üzerindeki veri katmanı, klasik yönteme göre iş akışlarınızı hızlandıracak, istek ve cevaplar oldukça hafif olan bir veri yapısı kullanacak (klasik yöntemde, verinin ne olduğunu bildiren, hatta her veri alanın ne olduğunu bildiren, çoğu zaman veri boyutundan daha fazla yer kaplayan header gibi bir data veya dataset gönderilecek).
  • Dördüncü durumda, bir önceki yapının avantajlarına ilave olarak, yönetimsel bir veri servisine sahip olacaksınız. Bu mimari de SOA olarak adlandırılmaktadır. SOA da birbirinden bağımsız birden çok servis eş zamanlı olarak çalışırlar. Optimizasyona açık, kolay güncellenebilir, bir servisin çalışmaması uygulamanın çalışmasını engellemez yalnızcaa ilgili modül çalışmaz. Performans açısından (karma veri servislerine nazar) oldukça iyidir.
WWW
Cevapla
#3
@Fesih ARSLAN hocam gayet iyi bir aciklama oldu.
Cok tesekkur ederim. Bastan plansiz yapilan projeler ileride geri donulnez noktaya gelebiliyor. Hem zaman hem is hemde psiklojik kayip oluyorWink
Semirler ilerledikce detaylara daha hakim olacagimiza inaniyorum tekrar tesekkurler
Cevapla


Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Web Service Eventing (WS-Eventing) Hakkında vkamadan 4 2.265 13-11-2017, Saat: 09:17
Son Yorum: vkamadan
  Database önerisi ybelen 3 1.401 17-04-2017, Saat: 10:16
Son Yorum: DelphiCanR



Konuyu Okuyanlar: 1 Ziyaretçi