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ı
#1
Information 
Delphi ile çok katmanlı mimariler/yapılar ve orm işaretlemeleri kullananlar için bir sorum olacak.

C# tabanında IDisposable interface'i yardımı ile Garbage Collector, dispose metodunun içinde kullanılmayan kaynakları suppressfinalize edebiliyor.

Ado bağlantıları için çok eskiden kalma bir bağlantı sınıfım var. Sonrasında FireDac için revize edip tek sınıfta yönetimi sağladım. Bu sınıfta her seferinde bağlantıyı kapatarak ciddi oranda işlem ve iş hacmi oluşturduğunu düşünüyorum. Özellikle soap hızını bir kenara koyarsak, daha da hızlandırabileceğimizi düşünüyorum.

Bağlantıları yönetmek yerine, bu işleri yapacak otomatik olarak yapacak ve kullanılmayan kaynakları ortadan kaldıracak bir sınıf, yapı yada sistem kullanan oldu mu? Veritabanına dair tüm işlemleri yapabileceğimiz (crud + sp) bir sınıf oluşturma konusunda nasıl bir yol izlenebilir?

Ado için c# ve vb tabanında kullandığımız dll yapımız mevcut ancak Object Pascal tabanlı projeler için ve tabi ileriye dönük olarak yatay genişletebileceğim bir "bireysel framework" ile orm modellemesi için güzel bir yapı oluşturmak adına tecrübelerinize dayanarak yönlendirmelerinizi bekliyorum.
{ talk is cheap show me the code. }
Cevapla
#2
Merhaba

Başıma bir şey gelmeyecekse;

Daha önce çok basit anlamda "ev yapımı" diye tabir edebileceğimiz, sadece map etmekten öteye gitmeyen bir orm kullandım, yazdım.

Bunun dışında Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol mevcut bazı çalışmalar var.Belki daha önce görmüşsünüzdür.
Daniele'nin projesindeki özelliklerde kulağa hoş gelen pek çok şey var sanki, indirip denemedim.
Fakat Unit testlerinin olması güven veriyor.Testler çalıştırılıp incelenebilir.

Kendi orm ve katmanlı mimarinizi kurmak gibi bir fikriniz varsa en temelinde RTTI üzerine yoğunlaşmanız gerekebilir.
Herkesin kendisine göre doğruların olduğu bir dünyada, tek bir sınıfın her türlü veritabanı işini yapması fikri ne kadar doğrudur bilemiyorum.
Fakat Poliformik(olmadı sanki) bir kodlama ile esnek bir tasarım yapılabilinir.

Gelebilecek çeşitli taleplere göre düşünüp, tasarımı o şekilde yapmak daha doğru olabilir.
Tabi kapitalizm size bunları düşünmeye fırsat verirse...
TQuery, TBilmemneQuery'yi doğrudan TFormun üzerine, usulca sürekleyip bırakmak, katmanlı mimari açısından çok doğru bir yaklaşım olmayabilir.Çünkü sunum(TForm) katmanı ile veri(TQuery)katmanı iç içe geçmiş ve çok sıkı bir şekilde bağlı durumdadır.Bu bağlar ne kadar düzeyde soyutlanabilirse, o kadar esnek bir tasarım yapılmış olur diye düşünüyorum.
My name is nobody.
WWW
Cevapla
#3
(19-07-2017, Saat: 11:41)ismailkocacan Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlMerhaba

Başıma bir şey gelmeyecekse;

Daha önce çok basit anlamda "ev yapımı" diye tabir edebileceğimiz, sadece map etmekten öteye gitmeyen bir orm kullandım, yazdım.

Bunun dışında Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol mevcut bazı çalışmalar var.Belki daha önce görmüşsünüzdür.
Daniele'nin projesindeki özelliklerde kulağa hoş gelen pek çok şey var sanki, indirip denemedim.
Fakat Unit testlerinin olması güven veriyor.Testler çalıştırılıp incelenebilir.

Kendi orm ve katmanlı mimarinizi kurmak gibi bir fikriniz varsa en temelinde RTTI üzerine yoğunlaşmanız gerekebilir.
Herkesin kendisine göre doğruların olduğu bir dünyada, tek bir sınıfın her türlü veritabanı işini yapması fikri ne kadar doğrudur bilemiyorum.
Fakat Poliformik(olmadı sanki) bir kodlama ile esnek bir tasarım yapılabilinir.

Gelebilecek çeşitli taleplere göre düşünüp, tasarımı o şekilde yapmak daha doğru olabilir.
Tabi kapitalizm size bunları düşünmeye fırsat verirse...
TQuery, TBilmemneQuery'yi doğrudan TFormun üzerine, usulca sürekleyip bırakmak, katmanlı mimari açısından çok doğru bir yaklaşım olmayabilir.Çünkü sunum(TForm) katmanı ile veri(TQuery)katmanı iç içe geçmiş ve çok sıkı bir şekilde bağlı durumdadır.Bu bağlar ne kadar düzeyde soyutlanabilirse, o kadar esnek bir tasarım yapılmış olur diye düşünüyorum.

Öncelikle kapsamlı cevabınız için teşekkür ederim.

Ev yapımının biraz ötesinde, piyasada koşan .net tabanlı projelerimizde n-tier mimari ve orm yapısını kurguladık. Her ne kadar adına framework diyemesem de, kendi işimizi yapacak, organik bağları olmayan, ihtiyaca göre yatay ve dikey genişleme imkanı sunan, bağımlılık derecesi çok düşük, iş katmanının kendi içinde çeşitli kırılımlara sahip olduğu bir yapımız mevcut.

Bu yapıyı şuan Pascal üzerinde de inşa ettim. Sadece Interface ve module yapılarını uygulamadan doğrudan Unit üzerinden kendi model yapımıza göre entegre edip, TAdoQuery ve TFDQuery içinde çalışır vaziyette ancak yukarıda belirttiğim gibi; Kullanılmayan kaynaklar ve AdoConnection/FDConnection session süresi boyunca ciddi bir trafik işgal edebiliyor.

Her ne kadar Access katmanının içinde execute işlemi sonrasında bağlantısını kapatsak dahi, oluşturulan her obje, her katman içinde çağırılan obje bir şekilde ram ve işlem gören db için bir olay/trafik/yer işgal ediyor. Bu sebepten ötürü kullandığımız her nesnenin oluşturulma anından itibaren yaşam döngüsünü kontrol edecek bir yazılım yazmak neredeyse imkansız hale geliyor. Bunu bizim yerimize otomatik yapacak bir yöntem var mıdır? Tekrar teşekkürler.
{ talk is cheap show me the code. }
Cevapla
#4
"Kullanılmayan kaynaklar" görünce ilk aklıma gelen;Bir nesne(kaynak) kullanılmıyorsa neden, hafızada yer tahsis ediliyor sorusu.

Anladığım kadarıyla .net GC mantığının karşılığını delphi tarafında arıyorsunuz.
Delphi üzerinde inşa ettiğiniz yapı ile ilgili basit bir prototip/örnek kod paylaşabilirseniz daha somut fikirlerler ortaya çıkabilir.Belki.
My name is nobody.
WWW
Cevapla
#5
(19-07-2017, Saat: 14:24)ismailkocacan Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol"Kullanılmayan kaynaklar" görünce ilk aklıma gelen;Bir nesne(kaynak) kullanılmıyorsa neden, hafızada yer tahsis ediliyor sorusu.

Anladığım kadarıyla .net GC mantığının karşılığını delphi tarafında arıyorsunuz.
Delphi üzerinde inşa ettiğiniz yapı ile ilgili basit bir prototip/örnek kod paylaşabilirseniz daha somut fikirlerler ortaya çıkabilir.Belki.

Kullanıcı tanımlı tiplerin manuel olarak allocated-deallocated edilmesi, 30+ modül yada ne kadar kapsamlı olduğunun bir anlamı olmadan, bir çok aşamada, her katman geçişinde kullanılan nesnelerin sırayla yönetilmesi ve küçük çaplı bir denetim sınıfı oluşturup sırayla deallocate edilmesi anlamına geliyor. Burada bir kestirme yol var mı anlamında sormuştum hocam Smile

Şayet olursa diye; Garbage Collector'ün sunduğu güzelliklerden Delphi'de de yararlanmak istiyorum diyebiliriz. Şöyle ki; eski projelerimiz Aspect-oriented olarak geliştirildi. Ide sürümünü xe5'ten xe8'e yükseltirken bazı yeni ihtiyaçlar doğrultusunda veritabanı yapılarımız dahil bir çok yapıda revizyon yaptık. Bu sebeple Object-oriented yaklaşımına ayak uyduracak şekilde, .net tarafındaki tecrübelerimizi bu tarafa aktaralım istedik. Durum aşağı-yukarı bu şekilde diyebilirim. Bu yapıya çevirme ihtiyacının bir ucu da, kendi ihtiyaçlarımız doğrultusunda yıllardır oluşturduğumuz kütüphaneleri çöpe atmadan, hızlı ve pratik bir uyarlama ile, yeni projelerimizde güzel ve esnek bir yapı altında kullanmak. Şayet beklentilerimin ötesine geçerse, biraz daha geliştirip açık yada kapalı kaynak olarak dağıtmayı da düşünürüm.

Dipnot: GC mantığı Delphi'de yok, bunu biliyorum. Bu yüzden kullanıcıya çok fazla yük yüklemeden, otomatikleştirerek kaynak yönetimi yapabileceğim bir yapı mevcut mu? Yada bahsettiğim şekli ile geliştirme yapanlar bu kaynakları nasıl yönetiyor? İyi günler.
{ talk is cheap show me the code. }
Cevapla
#6
Neyi 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.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#7
(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.
{ talk is cheap show me the code. }
Cevapla
#8
.net ve java gibi dillerde geliştirilen AOP framework ve yaklaşımların çoğunun temelinde, daha öncede bahsettiğim gibi reflection kütüphaneleri yatmaktadır.
Bunun hakkında daha önce @kimimben bir Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol yazmış.

Bildiğiniz üzere yazıda bahsedilen spring framework'de bir AOP uygulamasıdır aslında.Delphi tarafında Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol gibi bir framework mevcut.Hiç kullanmadım.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol testleri inceleyebilirsiniz.Belki beklentilerinizi karşılayabilir.

Dediğim gibi, kendiniz bile bir framework geliştirecek olsanız, delphi tarafında tık tık diye kapısını çalacağınız ilk kavram RTTI'dir.
RTTI'nin de temelinde aslında...
My name is nobody.
WWW
Cevapla
#9
(19-07-2017, Saat: 16:27)ismailkocacan Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol.net ve java gibi dillerde geliştirilen AOP framework ve yaklaşımların çoğunun temelinde, daha öncede bahsettiğim gibi reflection kütüphaneleri yatmaktadır.
Bunun hakkında daha önce @kimimben bir Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol yazmış.

Bildiğiniz üzere yazıda bahsedilen spring framework'de bir AOP uygulamasıdır aslında.Delphi tarafında Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol gibi bir framework mevcut.Hiç kullanmadım.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol testleri inceleyebilirsiniz.Belki beklentilerinizi karşılayabilir.

Dediğim gibi, kendiniz bile bir framework geliştirecek olsanız, delphi tarafında tık tık diye kapısını çalacağınız ilk kavram RTTI'dir.

Teşekkürler. Sanırım Spring4D ihtiyaçlarımı karşılamaya yeterli olacak gibi gözüküyor. Unit Testleri açısında bazı sorunları olduğunu duymuştum, gönderdiğiniz linkte de kısaca belirtilmiş. İlginiz için çok teşekkür ederim.
{ talk is cheap show me the code. }
Cevapla
#10
Rica ederim.
Pratikte aktif olarak kullandığım şeyler olmadığı için, benden de pek detaylı bilgi çıkmıyor.
My name is nobody.
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter



Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Firedac bileşenleri hakkında canbir 1 112 16-04-2018, Saat: 14:10
Son Yorum: canbir
  Unidac,Firedac,DbExpress,Ado,MyDac narkotik 4 230 07-04-2018, Saat: 09:23
Son Yorum: malitutuncu
Question Access 2016 BY-HAYALET 27 670 28-02-2018, Saat: 11:30
Son Yorum: Pimapen_Nuri
  Youtube için kesin çözüm nedir Lord_Ares 20 635 24-02-2018, Saat: 08:47
Son Yorum: Lord_Ares
Information Delphi Mail Gönderme İçin Alternatif hyperxman 4 741 27-12-2017, Saat: 21:14
Son Yorum: hyperxman



Konuyu Okuyanlar: 1 Ziyaretçi