(27-11-2017, Saat: 17:25)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: [ -> ] (27-11-2017, Saat: 17:03)Bahadir.Alkac Adlı Kullanıcıdan Alıntı: [ -> ]Merhaba,
İşin doğrusu ben de SOAP taraftarıyım. Ama SOAP'ın çok ciddi bir XML yükü var. Bu yüzden de özellikle yüklü miktarlarda veri göndermek istediğinizde çok fazla gereksiz XML verisi de göndermiş oluyorsunuz. REST API'si hem mimarisi, hem de genelde JSON kullandığı için bu sorun çok daha az.
Abdullah Bey, acaba siz kendi projelerinizde SOAP'ın bu ciddi XML veri yükünü yönetmek için bir şeyler yapıyor musunuz? Yapıyorsanız neler yapıyorsunuz? 
Teşekkürler
Bahadır Bey, öncelikle taraf güçlendirmesi yaptığınız için teşekkür ederim.
Projelerin genişleme türüne göre tedbir alıyoruz. Bir projenin sadece windows tabanlı (ki bu durumda da yapıyoruz) olmasında yaklaşım biraz değişiyor. Mobil, web ve masaüstü platformları ne kadar bir arada ve çeşitli işlemleri paylaşıyor olsa da, hepsinin uygulama katmanını web servis üzerinde yapıyoruz. Böylece her platforma has baştan kodlamalar yapılmıyor. Platform bazlı çeşitli kontrol ve denetimler dışında kapsülleme için oluşturulan veri tipleri dahi bu servisler üzerinde tasarlanıyor.
İlerleyen zamanda projeye 3. parti geliştirme yapmak isteyenler olduğunda altyapının müsait olmasından ötürü talep edilen metodların ayrılıp bir token ile verildiği ek servislere taşımak çok kısa oluyor. Orada da çok katmanlı mimari üzerinden servis geliştirdiğimiz için n tane asmx dosyasına business metodlarını çıkartmamızın bir sakıncası olmuyor.
Dokümantasyon işi çok fazla yük alıyor. Onun haricinde XML parse işlemleri ile uğraşmıyoruz. Doğrudan wsdl'den oluşan pas dosyaları ile yerel soap nesnesi oluşturup metodları invoke ediyoruz. Tek tip mantığını da veritabanına göre planladığımız zaman her platform için başka kişiler geliştirme yapacağını hesaba koyarsak; tek bir dil ve standart üzerine yoğunlaşılıyor. Metod imzaları, isimlendirmeler, complex types dediğimiz veri yönetimi için oluşturulan özel obje tiplerine kadar her şey ortak kalmış oluyor.
Her ne kadar xml yük gibi gözükse de, güvenliği ve kararlılığı açısından benim vazgeçmem ilk aşamada çok zor gözüküyor.
E-fatura gibi milyonlarca datanın aktığı sistemlerin altyapısının planlamasında xml tercih ediliyorsa bir sebebi vardır kesinlikle. Buradan yola çıkarak; UBL (evrensel iş dili) standartları gibi kendi jargonunuza has standart bir isimlendirme politikası çok ciddi anlamda kolaylık sağlar.
Siz nasıl yaklaşıyorsunuz peki? Yönetimi, kullanımı ve dağıtımı açısından neler planlıyorsunuz?
Merhaba,
Ben çok katmanlı mimari kurmak zorunda olduğum projelerde ORM nesnelerini binary veri olarak gönderiyorum. Aşağıda standart yapılarla benim kullandığım yapıya örnek veriyorum:
type TOgrenci = class(TRemotable)
published
// Öğrenci ile ilgili bilgiler burada
end;
function OgrenciEkle(AOgrenci: TOgrenci): TOgrenci;
Yukarıda iki tane ciddi sorun var:
1. TOgrenci, TRemotable sınıfından türemek zorunda ve serialize etmek istediğiniz bütün özellikler published kısmında yazılmalı.
2. XML içinde hem fonksiyon tanımı, hem de TOgrenci tanımı olmak zorunda.
Sadece öğrenci ekleyeceğiniz zaman çok ciddi sorun değil, ama bir de 10.000 kişilik öğrenci listesini almak istediniz diyelim. Tamam, 10.000 biraz kışkırtıcı bir sayı ama olsun
Aşağıda da benim kullandığım yapı var:
type TOgrenci = class(TMyBaseObject)
public
// Öğrenci ile ilgili bilgiler burada
procedure SaveToStream(AStream: TStream);
procedure LoadFromStream(AStream: TStream);
procedure SaveToDataSet(....);
procedure LoadFromDataSet(...);
class procedure DataSetToObjectList(...);
class procedure DataSetToStream(...);
end;
function OgrenciEkle(AOgrenci: TByteDynArray): TByteDynArray;
Dikkat edecek olursanız TOgrenci ciddi bir biçimde değişti. Burada açıklamam gereken bir şey var: TOgrenci aslında ucuz ve eksik bir ORM sınıfı. Daha çok kendi ihtiyaçlarıma göre tasarlanmış. Ben ORM kütüphanelerinde sorgu üretme kısmının gereksiz buluyorum. Bunun yerine stored procedure (SP) yazmak veya ORM sınıflarını extend edip gerekli fonksiyonu yeni sınıfın içine yazmak daha doğru geliyor. TOgrenci de aslında böyle. Kendi özelliklerini ve bazı fonksiyonlarını veri tabanına göre otomatik üretiyorum.
Avantajları şunlar:
- SOAP XML dosyası küçük oluyor, çünkü ortadaki tek tanım TByteDynArray gibi byte array.
- SOAP XML serialize etme işlemi çok güzel görünebilir, ama ciddi bir hız maliyeti var. Bu maliyeti ortadan kalkıyor. Onun yerine her sınıf kendisini herhangi bir stream'e yazmayı ve stream'den okumayı biliyor. Bu da çok hızlı veri transferi anlamına geliyor.
- Bu yapı sayesinde çok katmanlı mimarinin bütün avantajlarını kullanabiliyorum. Nesneler kendilerini DataSet'lere yazmayı bildiği için Client tarafında kullandığım bir MemTable sayesinde Delphi'nin TDataSource nesnesini kullanabiliyorum. Bu da istemci tarafında işleri inanılmaz derecede kolaylaştırıyor ve hızlandırıyor.
Herşey bu kadar güzel değil
Bu sistemin de bir takım sorunları var:
- Client ve Server daima aynı sürümde olmalı. Daha doğrusu veri tabanı nesneleri aynı sürüm olmalı. Bu da güncellemeleri biraz zorlaştırıyor.
- Fonksiyonların ve parametrelerin isimlendirmesine çok dikkat etmek gerekiyor. Aksi takdirde REST sistemlerinde karşılaştığımız sorun çıkıyor: Fonksiyonun ne iş yaptığını anlamak için doküman okumak gerekiyor. Ben bunu şöyle idare ediyorum: Çok özel durumlar hariç fonksiyon hep veri tabanındaki ismine uygun oluyor. Örneğin sadece öğrenci tablosundan bir kayıt alacaksam fonksiyonun adı OgrenciGetir oluyor, ama öğrencinin bazı detaylarını da JOIN ile alıp getirmem gerekiyorsa o SP'nin adını kullanıyorum. Yani SpOgrenciGetir oluyor. Tabii veri tabanında da SpOgrenci diye bir SP var. Kısaca fonksiyon/parametre adında kullanılması gereken sınıfla ilgili bir ipucu oluyor.
Alıntı:Bu mantıkla; Windows daha çok kullanıldığına göre vardır bir bildikleri. Yada Dünya'da Hristiyanlar daha fazla olduklarına göre vardır bir bildikleri 
İşin komiğibu mantık kısmen de olsa doğru
Windows'un bu kadar çok kullanılmasının sebebi Windows işletim sistemine her dilde çok kolay program yazılabilmesi. Ünlü "developers, developers, developers" lafını bilirsiniz. Programcılar kolay program yazıyorsa, kullanıcılar da mecburen o programları kullanacaklar. Günümüzde Apple kendi işletim sistemlerinde bunu bir nebze aştı ve mobil piyasayı anında değiştirdi. Peşinden Google yaptı aynısını. Her ikisinin de ortak noktası aynı: Yaratıcı, yeni ve kolay program yazılabilir olması. Burada şu ufak detayı gözden kaçırmayın: Windows'da, standart kullanıcıların rahatlıkla kullanabileceği (yani görsel) programlar yazmak çok kolay!
Bahadır Alkaç
