Tüm Platformlar için Hızlı Uygulama Geliştirme --->    Kitabımız...      Delphi

Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 5/5 - 1 oy
  • 1
  • 2
  • 3
  • 4
  • 5
FireDac ve Ado için Data Access Katmanı
#11
Dediğiniz GC yapısını bilmem ama 'Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol Teti' bahsedilen işler için çok güzel kütüphaneler yazmıştır. Github sayfasını incelemenizi öneririm. Kendim DORM projesini indirip incelemeye başladım. Şu an için sadece sqlite örneğini incelemekteyim. Henüz herhangi bir uygulamada denemedim ve ne kadar başarılı sonuçlar verir bilemiyorum.
WWW
Cevapla
#12
(19-07-2017, Saat: 16:22)Abdullah Ilgaz Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(19-07-2017, Saat: 15:36)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlNeyi nasıl kodladığınızı bilmeden afaki olarak konuşmak yahut fikir/öneri sunmak pek kolay değil. Ancak şahsi fikrim, GC gibi mekanizmaların programcıya (gerçek programcıya) pek fayda sağlamadığı yönündedir. Gerçek programcı kullanacağı nesneyi ihtiyacı olduğunda create edip, ihtiyacı kalmadığında yok edebilen kişidir. Delphi bunun için bir çok mekanizma sunmuş aslında. Birincisi hepinizin malumu olduğu üzere Owner mekanizması, bir diğeri de Interface'ler.

 ORM ile ilgili geliştirmeniz gereken en önemli kısım belki de bir adet Connection Pool. Dediğim gibi, yaptığınız implementasyonun bir kısmını sunabilirseniz(fikir verebilecek kadarını) daha isabetli yorumlar yapabilir ve belki de sizlere yardımcı olabiliriz.

Tuğrul Bey,

Kodun nasıl yazıldığından ziyade, asıl mesele GC mekanizmasının, ve dahi çeşitli Interface birimlerinin uygulamalara sunduğu avantajları, mümkün olduğu şekliyle Delphi'ye ve ortamına uyarlamak.

Programlama yaklaşımları, sistem kütüphaneleri ve dilin sunduğu avantajlar, sizin tabirinizle, "gerçek olmayan programcı"lara has şeyler değildir. Her birikim düzeyine hitap eden ayrı ayrı yapılar ve kurgular var. Neticede programlamanın özüne, derinliklerine inmek sonu olan bir şey değildir.

Cevaplardan anladığım kadarıyla, kullanılan sistemleri canlıya alıp yaşatabileceği sorunları denemeden çözüme ulaşamayacağım. Xml servislerinde bahsettiğiniz connection pool yapısını ancak ilk mesajımda yazdığım IDisposable interface'i sayesinde hızlı bir şekilde çözüme kavuşturmuştum. Halâ aktif olarak 10'un üzerinde xml servisi, 1000 civarı client tarafından işleniyor ve n tane sunucuya bağlanıp işlem yapıyor.

Belki burada ifademi şu şekilde revize edersem faydalı bir yönlendirme alabilirim; ortalama günlük 10.000-50.000 talep için işleme-çözümleme yapabilecek bir server aplikasyonunda, bağlantıları yönetecek sınıfın kullanılmayan kaynaklarını denetlemesini kolaylaştıran bir yapı (gc mantığı) mümkün mü? (Bireysel geliştirmelerden bahsetmiyorum)

Her ne kadar business katmanında nesneleri oluştur, kullan, yok et prensibine sadık kalarak geliştirme yapılsa da, her geliştiricinin her satırına tek tek inceleme yapıp ona göre hareket etmek neredeyse imkansız. Bu da revizelerin yükünü ciddi oranda arttırıyor. İlginiz için çok teşekkürler.

Abdullah Bey,

Sanırım yazdığım gerçek programcı vurgusu hususunda bir alınganlık göstermişsiniz, yahut ben öyle hissettim. Şahsınıza yönelik bir vurguda bulunmadım. İnandığım şeyi yazdım cidden.

Alıntı:Kodun nasıl yazıldığından ziyade, asıl mesele GC mekanizmasının, ve dahi çeşitli Interface birimlerinin uygulamalara sunduğu avantajları, mümkün olduğu şekliyle Delphi'ye ve ortamına uyarlamak.

GC gibi bir mekanizmanın programcılara netice itibari ile avantaj sunduğunu düşünmüyorum. Interface hususuna gelirsek, Delphi zaten bu mekanizmayı sonuna kadar destekliyor, kullanmamak için bir neden yok.

Alıntı:Programlama yaklaşımları, sistem kütüphaneleri ve dilin sunduğu avantajlar, sizin tabirinizle, "gerçek olmayan programcı"lara has şeyler değildir. Her birikim düzeyine hitap eden ayrı ayrı yapılar ve kurgular var. Neticede programlamanın özüne, derinliklerine inmek sonu olan bir şey değildir.

Ben yukarıdaki paragrafta söylediğiniz şeyi hiç bir yazımda kast etmedim. Gerçek programcı zaten dilin sunduğu avantajları kullanmalıdır. Ama önce ne yaptığını bilmeli ve anlamalıdır. Aksi taktirde, programcı değil kullanıcı olur.

 Bilemiyorum, beni ne kadar tanıyorsunuz; ama her zaman aşağı seviye programlamayı bilmenin, öğrenmenin faydalarına inanan ve bu hususta az olan bilgim ile insanlara yardımcı olmaya gayret eden bir yapım var. Kalp kırmayı hiç sevmiyorum, ama bazen yanlış anlaşılabiliyorum sanırım. Bu vesile ile kalbinizi kırdı isem affola.

 Lâkin GC denilen mekanizma; kısaca nesneyi create et ve unut anlamına gelir. Bu, kendisine programcı diyen arkadaşlarımız için büyük bir kolaylık gibi görünüyor olabilir. Ama aslında tembel programcıların çoğalmasına ve ne yaptığını bilmeyen insanların ciddi programlar yazmasına zemin hazırlar.

 Nesneyi create ettim, peki ne zaman bu nesne free olacak ? GC'de malum bir nesil algoritması vardır ve ara ara nesiller kontrol edilir. Dolayısı ile arka planda her bir nesneyi bir nesille ilişkilendiren ve bu nesilleri ara ara kontrol eden bir mekanizma mevcut. Böyle bir mekanizma sisteme yük getirir mi ? Cevap sizlerin.

Oysa, işi biten bir nesnenin ne zaman yok edileceğini en iyi onu create eden programcı bilir. Öyle değil mi ?

Peki elimizde neler var ?

1- Owner mekanizması var. Yani, bir nesneyi bir başka nesnenin sahiplenmesi. Sahiplenen nesne free edilir iken(Destroy), sahip olduğu nesneleri de otomatik olarak yok edecektir.

2- Interface'ler ile referans sayımı mekanizması var. Yani, her bir nesneye refere olan değişkenler, başka bir yeri refere etmeye başladığında ya da ilgili scope'dan çıkıldığında nesnenin referans sayısı bir azalacak ve referans sayısı sıfır'a ulaştığında nesne otomatik olarak free edilecektir.

 Programlama bir disiplin işidir gerçekten de. Programlama disiplini içinde kullanılan hiç bir şeye (anlaşıldığı müddetçe) karşı çıkmam ama, GC gibi mekanizmaların bu disiplini bozduğunu, insanları tembelliğe alıştırdığını düşünüyorum. Benzer düşünceleri .Net FW için ya da sadece VCL/FMX ile yetinenler için de düşünmüyor değilim hani.

 Örneğin her gün kullandığımız Delphi'nin OOP desteğine sahip olduğunu pek çok programcı arkadaşımız bilir ama bunu nasıl yaptığını bilir mi ? Polymorphism'i nasıl gerçeklediğini bilir mi ? Virtual Method Table (VMT), Dynamic Method Table (DMT), Interface Method Table (IMT) gibi kavramların aslında her gün kullandığımız şeyler olduğunun farkındalar mı ?

Ben pek sanmıyorum maalesef. Bir ara Low Level bölümümüze de bekliyoruz sizleri inşallah.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#13
Alıntı:Abdullah Bey,

Sanırım yazdığım gerçek programcı vurgusu hususunda bir alınganlık göstermişsiniz, yahut ben öyle hissettim. Şahsınıza yönelik bir vurguda bulunmadım. İnandığım şeyi yazdım cidden.

...

GC gibi bir mekanizmanın programcılara netice itibari ile avantaj sunduğunu düşünmüyorum. Interface hususuna gelirsek, Delphi zaten bu mekanizmayı sonuna kadar destekliyor, kullanmamak için bir neden yok.

Tuğrul Bey,

Estağfirullah, üzerime alınmadım hocam. Orada bahsettiğim şey kullanılan teknolojinin sunduğu faydalardan sonuna kadar yararlanma arzusu. Tabiri caizse alınan lüks otomobilde hiç kullanılmayan özelliklerle yıllarını geçirenler olduğu kadar, en küçük fonksiyonunu öğrenip kullananlarda oluyor.

Bu tarz mekanizmaların sağladığı avantajları yıllar içerisinde tecrübe ettikçe kullanmaya başladım. Bir yerden sonra bazı şeyleri sorgulamayı bırakıp, ne olduğunu öğrenip deneyerek; "evet, bu işe yarıyor ve güzel bir olay" diyerek kullanıyorum.

Tek başıma geliştirdiğim dönemlerde bu tarz mekanizmalar çok anlam ifade etmiyordu hocam. Çünkü her aşamasında, her olayında ve neticesinde olacakları hızlı hızlı alpha-beta testlerine tabi tutup, çoğu şeyi gözden geçirdikten sonra müşteriye sürüm olarak dağıtıyordum.

Ancak geliştiriciler artmaya başlayınca, denetimler ve süreçler artmaya başlayınca, onların kodlarını revize etmek bazen aşırı dikkat gerektirebiliyor. Hatta tüm koda hakimiyet sağlamak adına saatler harcanabileceği için, bu tarz mekanizmalar, kodcu hatasını neredeyse sıfıra indirgeyebiliyor. Bu yüzden programlama yaklaşımları, hazır kütüphaneler, avantajlar, yazılım örüntüleri, kalıplar, factoryler, oop ve aop yapıları, soyut somut sınıflar, interface'ler, ciddi avantajlar sağlayabiliyor.

Alıntı:Ben yukarıdaki paragrafta söylediğiniz şeyi hiç bir yazımda kast etmedim. Gerçek programcı zaten dilin sunduğu avantajları kullanmalıdır. Ama önce ne yaptığını bilmeli ve anlamalıdır. Aksi taktirde, programcı değil kullanıcı olur.

Benim söylemlerim biraz yanlış anlam oluşturmuş, kusura bakmayın  Shy  

Gerçek programcı olarak kastettiğiniz, yaptığı şeylerin hepsine tam hakimiyet gösterebilen, sorunsuz işler çıkartabilen, iyi iş yapıp, geri dönüş ve revizesi az olan kişiler oluyor, anladığım kadarıyla. Değil kaynak yönetimi, hiyerarşi, katmanlı mimari... spagetti kod demeye şahit ister tarzda kod yazanların, obje isimlendirmelerindeki fiyaskolarını hesaba katarak; sizin bahsettiğiniz gerçek olmayanlar onlar oluyor sanırım, doğru muyum hocam?

 
Alıntı:Bilemiyorum, beni ne kadar tanıyorsunuz; ama her zaman aşağı seviye programlamayı bilmenin, öğrenmenin faydalarına inanan ve bu hususta az olan bilgim ile insanlara yardımcı
olmaya gayret eden bir yapım var. Kalp kırmayı hiç sevmiyorum, ama bazen yanlış anlaşılabiliyorum sanırım. Bu vesile ile kalbinizi kırdı isem affola.

Daha önce web sayfanıza denk gelmiştim hocam. Emeğinize, yüreğinize sağlık. Dijital ortamda ses-mimik-hareket olmadığı için anlamlar tam yansıtmayabiliyor. Bu bağlamda, size kırılmadım, siz de kırmadınız, lütfen. Ben yanlış bir söz ettiysem, sizi üzdüysem, kusura bakmayın.

Alıntı: Lâkin GC denilen mekanizma; kısaca nesneyi create et ve unut anlamına gelir. Bu, kendisine programcı diyen arkadaşlarımız için büyük bir kolaylık gibi görünüyor olabilir. Ama aslında tembel programcıların çoğalmasına ve ne yaptığını bilmeyen insanların ciddi programlar yazmasına zemin hazırlar.

 Nesneyi create ettim, peki ne zaman bu nesne free olacak ? GC'de malum bir nesil algoritması vardır ve ara ara nesiller kontrol edilir. Dolayısı ile arka planda her bir nesneyi bir nesille ilişkilendiren ve bu nesilleri ara ara kontrol eden bir mekanizma mevcut. Böyle bir mekanizma sisteme yük getirir mi ? Cevap sizlerin.

Oysa, işi biten bir nesnenin ne zaman yok edileceğini en iyi onu create eden programcı bilir. Öyle değil mi ?

Peki elimizde neler var ?

1- Owner mekanizması var. Yani, bir nesneyi bir başka nesnenin sahiplenmesi. Sahiplenen nesne free edilir iken(Destroy), sahip olduğu nesneleri de otomatik olarak yok edecektir.

2- Interface'ler ile referans sayımı mekanizması var. Yani, her bir nesneye refere olan değişkenler, başka bir yeri refere etmeye başladığında ya da ilgili scope'dan çıkıldığında nesnenin referans sayısı bir azalacak ve referans sayısı sıfır'a ulaştığında nesne otomatik olarak free edilecektir.

 Programlama bir disiplin işidir gerçekten de. Programlama disiplini içinde kullanılan hiç bir şeye (anlaşıldığı müddetçe) karşı çıkmam ama, GC gibi mekanizmaların bu disiplini bozduğunu, insanları tembelliğe alıştırdığını düşünüyorum. Benzer düşünceleri .Net FW için ya da sadece VCL/FMX ile yetinenler için de düşünmüyor değilim hani.

 Örneğin her gün kullandığımız Delphi'nin OOP desteğine sahip olduğunu pek çok programcı arkadaşımız bilir ama bunu nasıl yaptığını bilir mi ? Polymorphism'i nasıl gerçeklediğini bilir mi ? Virtual Method Table (VMT), Dynamic Method Table (DMT), Interface Method Table (IMT) gibi kavramların aslında her gün kullandığımız şeyler olduğunun farkındalar mı ?

Ben pek sanmıyorum maalesef. Bir ara Low Level bölümümüze de bekliyoruz sizleri inşallah.

Hocam sondan başlayayım Rolleyes

İnşallah. Ancak low level için puan meselesi var. Tamamlandığı zaman orada başınızı çok ağrıtacağım. Beyin fırtınası için ideal bir bölüm.

OOP merkezli programlama da sistem kurgusu ister istemez yazılımcıyı birçok ek yapıya zorluyor. Nesne yönelimli değil, merkezli dememin sebebi de esasen budur. Çoğu kişi yeni bir dili öğrenme korkusu yaşıyor. Aslında bahsettiğiniz tembellik bunun sebebi hocam. Ama ben programlamanın tembel işi olduğuna inanıyorum Smile Az eforla çok iş yapmamız buradan gelmiyor mu?

Ama şu var; disiplinli, istikrarlı ve sistematik proje geliştirmenin getirdiği aşırı sorumluluk ve buna ölçekle konfor var. Tek bir teknolojide çeşitli aşamaları geçtikten sonra, mevcut bilgiye bir nokta dahi eklemeden son çalıştığı güne kadar ilerleyenler oluyor. Bu noktada, gerçek programcı kavramımıza bir cephe daha açmış bulunuyorum.

Owner ve Interface yapıları aktif olarak uzun zamandır kullandığım yapılar. Özellikle Interface yapısı, uygulama-denetim olarak iki aşamada ele alırsak, denetim anlamında da ciddi bir kaide çizerek, büyük resmi belirginleştiriyor. İyi bir kodcu sadece oluşturulan interface'ler doğrultusunda ilerlerse, nokta bulmaca misali tüm noktaları birleştirebilir.

GC'ye ihtiyacımız daha çok havuz-SaaS-server side mimarilerde tek noktadan geçiş yapılan ve veri akışını denetleyici olarak belirleyen uygulamalarda her session, thread, nesne ve connection süreçlerini sağlıklı bir şekilde allocate-deallocate etmek için avantajlı oluyor hocam.

Low level'da (en yakın zamanda) görüşmek dileğiyle, İyi günler diliyorum. Vaktiniz, emeğiniz ve cevabınız için tekrar teşekkürler.
Save
{ talk is cheap show me the code. }
Cevapla

Konuyu Paylaş : facebook gplus twitter



Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
Question Access 2016 BY-HAYALET 23 297 Bugün, Saat: 01:31
Son Yorum: mcuyan
Information Delphi Mail Gönderme İçin Alternatif hyperxman 4 603 27-12-2017, Saat: 21:14
Son Yorum: hyperxman
  Firedac Helper Tuğrul HELVACI 10 286 22-12-2017, Saat: 11:31
Son Yorum: Tuğrul HELVACI
  Firedac Hakkında Tuğrul HELVACI 6 276 23-11-2017, Saat: 18:52
Son Yorum: Abdullah ILGAZ
Question Uzak Bir Bilgisayar İçin Port Ekleme? hyperxman 21 822 22-11-2017, Saat: 00:03
Son Yorum: nguzeller



Konuyu Okuyanlar: 1 Ziyaretçi