Konuyu Oyla:
  • Derecelendirme: 5/5 - 1 oy
  • 1
  • 2
  • 3
  • 4
  • 5
3 Katmanlı mimari/Delphi
#11
(21-12-2016, Saat: 13:02)Bahadir.Alkac Adlı Kullanıcıdan Alıntı: Çok katmanlı mimariler, Client/Server mimarilere göre yavaştır. Araya giren her katman da sistemi biraz daha yavaşlatır. Bu mimari hızı değil, veri güvenliği, sistem güvenliği, yük ve denge, kuralların yönetilmesi gibi farklı konuları ön plana çıkarır. 

Benim tavsiyem işe SOAP sunucu ile başlamanızdır. Delphi'de bunun bir sihirbazı da var. Bence VCL Application seçin (debug etmesi kolay olur), mimarinin mantığını kavrayın. Gerisi zaten yavaş yavaş gelecektir.

İyi çalışmalar

Bilgiler için teşekkür ederim. Örnek bir kargo firmasını ele alacak olursak onlarda çok katmanlı mimari kullanıyor ama pek bir yavaşlık olduğunu duymadım.

“Do. Or do not. There is no try.”
Cevapla
#12
Alıntı:Bilgiler için teşekkür ederim. Örnek bir kargo firmasını ele alacak olursak onlarda çok katmanlı mimari kullanıyor ama pek bir yavaşlık olduğunu duymadım.

Bahsettiğimiz yavaşlık göreli bir yavaşlıktır. Az veri içeren işlemlerde fark çok belli olmayabilir, ama veri miktarı büyüdükçe fark daha hissedilir hale gelir. Aslında basit bir mantıklı bunu görmek mümkün. Client/Server mimaride, Server dediğiniz genelde veri tabanıdır. İstemci ise kullanıcının kendisi. Biz istemciye veri tabanı bilgilerini (yani server bilgilerini) giriyoruz. İstemci de bu veri tabanından veri çekiyor (bildiğimiz SELECT sorgusu ile). Çok katmanlı mimarilerde istemci bir şey istediği zaman bunu sunucuya söylüyor (SOAP, REST veya herhangi bir protokol ile). Sunucu isteğe göre veri tabanına bağlanıyor ve veriyi çekiyor (Bu kısım Client/Server ile aynı gibi). Sonra bu veriyi paketliyor ve istemciye gönderiyor. İstemci gelen paketi açıyor ve kullanmak istediği formata çeviriyor. Yani arada bir sürü ek işlem var. Tabii sizin sunucudan bir seferde çektiğiniz kayıt sayısı az ise bu ek işlemlerin yaptığı etki fark edilmeyebilir. Ama sunucudan çekilen veri miktarı arttıkça yavaşlık adam akıllı hissedilir.

Bir de çok katmanlı mimariler ile web uygulamarı çok karıştırılır. Özellikle MVC yapısında tasarlanmış web siteleri. Bunlar aynı değildir. MVC yöntemi ile tasarlanmış bir web sitesi hala Client/Server mimari ile geliştirilmiş olabilir. Ve bu web sitesi, 3. parti uygulamalar için web servisleri de yazmış olabilir. Bu yüzden gerçek altyapıyı görmeden çok kesin yorum yapmak doğru değil.

İyi çalışmalar
Cevapla
#13
(21-12-2016, Saat: 14:11)Bahadir.Alkac Adlı Kullanıcıdan Alıntı:
Alıntı:istemcilerin delphi ile yazılmalı kısmını anlayamadım.

Datasnap kullandığınız takdirde sunucu/istemci arasında ClientDataSet gönderebiliyorsunuz. Yani aslında çok katmanlı mimariyi, Client/Server gibi programlayabiliyorsunuz. Bu da Rapid Application Development için inanılmaz bir pratiklik. Ama ClientDataSet gönderdiğiniz fonksiyon (procedure) .NET veya Java istemcisinde çalışmaz, çünkü ClientDataSet diye bir şey .NET veya JAVA'da yok. Dolayısıyla onlar için farklı bir fonksiyon yazmanız gerekir. Buradan çıkacak sonuç ise şu: Eğer bütün istemciler Delphi olacaksa Datasnap iyi bir fikir olabilir (elbette başka kriterler de var), ama farklı programlama dillerinde de istemci yazılacaksa o zaman Datasnap yerine SOAP/REST gibi standart bir sistem kurmak daha iyi bir fikir olabilir.
Hızlı uygulama geliştirmek adına , bu işi ClientDataset üzerine inşa etmek ne kadar doğru bir yaklaşım olabilir.
Servis odaklı bir mimari varsa, bu servisi tüketecek olan client uygulamanın programlama dili ve platformdan bağımsız olması gerekir diye düşünüyorum.

Aynı şekilde Datasnap sunucusu ile iletişimde JSON formatında veri kullanıldığında, hem istemci, hem de sunucuda bu JSON veri ilgili sınıf/tip'lere dönüştürülebilir.

Buradan farklı bir sonuç çıkaracak olursak;
Datasnap sunucuyu ClientDataset üzerine inşa etmez isek, o zaman client uygulamaları (masaüstü , mobil, web) delphi ile yazılması gibi durum söz konusu olmayacaktır.
Konuyla ilgili bulduğum bir örnek
One of the major software engineering challenges is managing change.
Cevapla
#14
(21-12-2016, Saat: 16:54)kimimben Adlı Kullanıcıdan Alıntı:
(21-12-2016, Saat: 14:11)Bahadir.Alkac Adlı Kullanıcıdan Alıntı: Datasnap kullandığınız takdirde sunucu/istemci arasında ClientDataSet gönderebiliyorsunuz. Yani aslında çok katmanlı mimariyi, Client/Server gibi programlayabiliyorsunuz. Bu da Rapid Application Development için inanılmaz bir pratiklik. Ama ClientDataSet gönderdiğiniz fonksiyon (procedure) .NET veya Java istemcisinde çalışmaz, çünkü ClientDataSet diye bir şey .NET veya JAVA'da yok. Dolayısıyla onlar için farklı bir fonksiyon yazmanız gerekir. Buradan çıkacak sonuç ise şu: Eğer bütün istemciler Delphi olacaksa Datasnap iyi bir fikir olabilir (elbette başka kriterler de var), ama farklı programlama dillerinde de istemci yazılacaksa o zaman Datasnap yerine SOAP/REST gibi standart bir sistem kurmak daha iyi bir fikir olabilir.
Hızlı uygulama geliştirmek adına , bu işi ClientDataset üzerine inşa etmek ne kadar doğru bir yaklaşım olabilir.
Servis odaklı bir mimari varsa, bu servisi tüketecek olan client uygulamanın programlama dili ve platformdan bağımsız olması gerekir diye düşünüyorum.

Aynı şekilde Datasnap sunucusu ile iletişimde JSON formatında veri kullanıldığında, hem istemci, hem de sunucuda bu JSON veri ilgili sınıf/tip'lere dönüştürülebilir.

Buradan farklı bir sonuç çıkaracak olursak;
Datasnap sunucuyu ClientDataset üzerine inşa etmez isek, o zaman client uygulamaları (masaüstü , mobil, web) delphi ile yazılması gibi durum söz konusu olmayacaktır.
Konuyla ilgili bulduğum bir örnek

Haklısınız, zaten bu yorumu da düşünerek "...Datasnap yerine SOAP/REST gibi standart bir sistem kurmak daha iyi bir fikir olabilir" demiş, kesin bir yargıdan kaçınmaya çalışmıştım. 

Hangi kütüphanenin seçileceği elbette projeye, projedeki mühendislere ve/veya programcılara, projenin süresine ve bütçeye göre karar verilecek bir şey.
Cevapla
#15
(21-12-2016, Saat: 16:34)Bahadir.Alkac Adlı Kullanıcıdan Alıntı:
Alıntı:Bilgiler için teşekkür ederim. Örnek bir kargo firmasını ele alacak olursak onlarda çok katmanlı mimari kullanıyor ama pek bir yavaşlık olduğunu duymadım.

Bahsettiğimiz yavaşlık göreli bir yavaşlıktır. Az veri içeren işlemlerde fark çok belli olmayabilir, ama veri miktarı büyüdükçe fark daha hissedilir hale gelir. Aslında basit bir mantıklı bunu görmek mümkün. Client/Server mimaride, Server dediğiniz genelde veri tabanıdır. İstemci ise kullanıcının kendisi. Biz istemciye veri tabanı bilgilerini (yani server bilgilerini) giriyoruz. İstemci de bu veri tabanından veri çekiyor (bildiğimiz SELECT sorgusu ile). Çok katmanlı mimarilerde istemci bir şey istediği zaman bunu sunucuya söylüyor (SOAP, REST veya herhangi bir protokol ile). Sunucu isteğe göre veri tabanına bağlanıyor ve veriyi çekiyor (Bu kısım Client/Server ile aynı gibi). Sonra bu veriyi paketliyor ve istemciye gönderiyor. İstemci gelen paketi açıyor ve kullanmak istediği formata çeviriyor. Yani arada bir sürü ek işlem var. Tabii sizin sunucudan bir seferde çektiğiniz kayıt sayısı az ise bu ek işlemlerin yaptığı etki fark edilmeyebilir. Ama sunucudan çekilen veri miktarı arttıkça yavaşlık adam akıllı hissedilir.

Bir de çok katmanlı mimariler ile web uygulamarı çok karıştırılır. Özellikle MVC yapısında tasarlanmış web siteleri. Bunlar aynı değildir. MVC yöntemi ile tasarlanmış bir web sitesi hala Client/Server mimari ile geliştirilmiş olabilir. Ve bu web sitesi, 3. parti uygulamalar için web servisleri de yazmış olabilir. Bu yüzden gerçek altyapıyı görmeden çok kesin yorum yapmak doğru değil.

İyi çalışmalar
MVC paternini biraz djangodan ve opencartan biiyorum. rest ve soap hakkında şimdiye kadar edindiğim bilgiye göre rest daha hafif soapa göre araştırmalara devam.

“Do. Or do not. There is no try.”
Cevapla
#16
3 cu katman sistemlerinde benim aklıma takılan nokta güvenlik başka biri veri alıp vermesini engel olmanın kesin bir yolu var ben şuan karışık bilgi gönderme ve kullanıcı bazlı şifre kontorul ile veri ayıp gönderme yöntemi şeklinde çözüm buldum.
Cevapla
#17
(21-12-2016, Saat: 09:57)edo Adlı Kullanıcıdan Alıntı: Linkteki bilgiler ışığında DataSnap'ın performans durumu nedir, iddia edildiği gibi rakiplerinin fersah fersah gerisinde/uzağında mıdır? Sizlerin yorum ve özellikle tecrübeleriniz nedir?

requests_per_second_01.png

memory_consumption_01.png?w=1008


Ne yazık ki evet yerlerde sürünüyor..
Blog yazısına yapılan yorumları okurken bir okuyucu Delphi Berlin 10.1 ile denediğini ve aynı sonuçları aldığını yazmış.. 

Mormot dikkatimi çekti.. Şuan bende bir arayış içerisindeyim..
Amatör Küme Bilgisayar Programcısı
WWW
Cevapla
#18
Açıkçası mormot'un çok fazla dokümanı var kendilerinin de belirttiği gibi ama anlaşılması çok basit değil ne yazık ki.

Bir de Spring4D içersine Marshmallow diye bir ORM framework'ünü eklemeye başlamışlardı (https://bitbucket.org/soundvibe/marshmallow/wiki/Home) tekrar vazgeçmedilerse ama kendi kullandığınız bileşenler için implemente edilmesi gereken çok fazla interface var ve ne ne işe yarıyor çok belli değil, ben içinden çıkamayıp bırakmıştım  Big Grin

Ayrıca devArt ve TMS'e ait de ORM araçları var ama hangisinin performansı nedir, ileriye dönük ne kadar süre daha destekleri olur muamma.

Ayrıca Delphi'nin bu konuda bu kadar güçsüz bir çözüm ile geliyor olması da ayrı kızdırıcı bence  Dodgy
Cevapla


Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Delphi 10.3 Rest Debugger sorunu varyemez 4 137 Dün, Saat: 01:36
Son Yorum: varyemez
  python, c++ for delphi tarzında eğitim, delphi ile diller arası entegrasyon eroniko 3 109 26-05-2020, Saat: 18:15
Son Yorum: engerex
  Delphi 10.3 Rio KeyBindings Abdullah ILGAZ 5 237 19-05-2020, Saat: 02:37
Son Yorum: Abdullah ILGAZ
Lightbulb Delphi Proje Yardım ThePixeL 18 1.256 29-04-2020, Saat: 02:28
Son Yorum: ThePixeL
  delphi clamav library sorunu, eroniko 6 443 27-04-2020, Saat: 03:27
Son Yorum: eroniko



Konuyu Okuyanlar: 1 Ziyaretçi