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ı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.Ç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ı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.
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 Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.
One of the major software engineering challanges is managing change.
Cevapla
#14
(21-12-2016, Saat: 16:54)kimimben Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.
(21-12-2016, Saat: 14:11)Bahadir.Alkac Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.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 Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.

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ı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.
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ı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız. 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ı (Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.) 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 Rest Api yhackup 20 3.535 01-10-2019, Saat: 18:30
Son Yorum: Mert_37
  Delphi'den SP ile kayıt Aktolgali 4 208 30-09-2019, Saat: 23:05
Son Yorum: Aktolgali
  Delphi & C# & Java Tuğrul HELVACI 25 1.254 30-09-2019, Saat: 10:36
Son Yorum: Tuğrul HELVACI
  Delphi Yeni Sürümlerde Fonksiyon Tanımlama Hayati 4 166 30-09-2019, Saat: 10:05
Son Yorum: Fesih ARSLAN
  Delphi Örnek Login Ekranı mehmetalpgozbasi 9 1.356 18-09-2019, Saat: 12:55
Son Yorum: wiseman



Konuyu Okuyanlar: 1 Ziyaretçi