Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5
LiveBindings belası!
#11
Sevgili Bahadır.Alkac Kardeşim,

Uzun açıklama ve kod örneği için teşekkür ediyorum.

90'lı yıllarda Delphi ile çalışma yaparken Türkiye'deki diğer programcılarla pek bir iletişimim olmadı. O yıllarda hep yurtdışı forumları / bağlantıları kullandım.
Behsettiğiniz zorluklarla ilgili de yurtdışında hiçbir belirtiye rastlamamıştım.

Lakin dikkat çekmek istediğim mesele biraz farklı. Yazdıklarınızdan özetle şu anlıyorum:

1) Eskiden TDatasource ile TDBxxx bileşen bağlantısı yapıyorduk. Şimdi LiveBindings ise herşeyi herşeye bağlıyoruz.
2) Madde #1'deki kolaylıklar yerli programcılarımızı işin fazlaca kolayına kaçıp yazılım mimarisindeki esasları pas geçmelerine yol açtı.
3) Ne eski TDBxxx ne de yeni LiveBindings özellikleri aslında çok katmanlı yazılım mimarisi açısından uygun değil; bunun yerine -yukarda verdiğiniz örnek kodda olduğu gibi- kendi kütüphanelerimizi oluşturara ilerleyebiliriz.

Madde #1'e katılıyorum. Madde #3'e katılmıyorum. Şöyle ki:

Madde #3:
Delphi'nin çıktığı 90'lı yıllar istemci/sunucu (client/server) mimarisinin pazarlandığı yıllardı. Bunun arka planında da büyük kuruluşların (Banka/Finans/Havayolu vs) IBM Mainframe sistemlerine aşırı bağımlı olması yatıyordu. Mainframe'de (diğer adıyla "yeşil ekranlar") her şey çok stabil bir şekilde ana sunucuda çalışıyordu. Finansal olarak bu sistemlerin alımı ve bakımı çok pahalıydı ve teknik açıdan da entegrasyon, ekranda işlevsellik konularında sıkıntılar vardı.

Bunun üzerine IBM'in rakibi olan IT devleri bir çıkış stratejisi için client/server mimarisine yöneldiler. Böylece büyük ve pahalı bir mainframe yerine artık sadece bir veritabanına ve bilgileri istemci tarafında işleyecek zengin programlara (dolayısıyla programcılara) ihtiyaç vardı. Bu strateji öncelikle Oracle / Sybase / Informix gibi veritabanı firmalarına ve Microsoft gibi işletim sistemi ve programalama dili geliştiricilerine yaradı (zaten IBM'e karşı birleşmelerinin ana sebebi buydu).

İstemci/Sunucu mimarisinde iş kurallarını hem veritabanında hem de istemci tarafında yazabilirdiniz. Hangi taraf daha hızlı ve anlamlı ise orayı seçiyordunuz. Oracle'ın zaten çok güçlü bir PL/SQL'i vardı ve bu süreçte büyük kuruluşlar ağırlıklı olarak çok güvenili bulunan Oracle'ın içinde veritabanı programlaması yaptılar. Microsoft ise Sybase'in bir fork'u olarak MSSQL'i çıkardı (ama o tarihlerde row-level-lock bile desteklenmiyordu). Microsoft aynı zamanda Visual Basic'i piyasaya sürdü (ama interpreted bir dil olarak epey yavaş ve sıkıntılıydı). Delphi ise bu süreçte "hem vb'nin kolaylığı hem de C'nin hızı" sloganıyla çıktı.

Bu tarihçeden sonra geleceğim nokta: TDatasource (ya da genel Datasource) mantığı hem VB hem de Delphi'de "istemci/sunucu mimarisinin bir olmazsa olmazı olarak" vardı.

Sonraları istemci/sunucu mimarisinin istemcileri upgrade/patch/deployment etmekle ilgili sıkıntıları ortaya çıktı.
...Ve aynı firmalar dediler ki: "Client/Server out Multi Tiered in".

Dolayısıyla herkes Multi Tiered Architecture'a (Çok Katmanlı Mimari) dönmeye başladı. Aslında iş öncelikle "3 katmanlı mimari" olarak başladı; yani Veritabanı - İş Katmanı - Sunum Katmanı (Database Layer - Business Logic Layer - Presentation Layer).
Zamanla ölçeklenebilirlik/sanallaştırma vs. derken "üç katman" "çok katman"a evrildi.

Böylece IBM Mainframe'in basit yeşil ekranlarından web sunucularının aynı ölçüdeki "beceriksiz" ekranlarına dönmüş olduk. "Tarih tekerrürden ibarettir" diye boşuna dememişler. HTML5/AJAX vs. çok sonradan geldi. Delphi'nin popülerliğini yitirdiği nokta da web tabanlı sunum katmanı için bir cevabının olmamasıydı. Zaten o ara Bill Gates Delphi'nin baş mimarını kandırıp Microsoft'a aldı ve .Net ile C#'ı geliştirdiler. Delphi'nin sonuydu. Tekrar geri gelişi ancak mobil dünyanın gelişmesiyle oldu.

Fazla tarihçeye boğulmayalım:

TDatasource, her ne kadar istemci/sunucu için presentation layer için bir zorunluluk idiyse de aslında bir sunum katmanı bileşeni değildi (zaten sadece design time'da var). Sunum katmanı ile veritabanı arasındaki bağlantıyı kuruyordu. Daha da genelleştirirsek, sunum katmanı ile VERİ KATMANI arasındaki bağlantıyı kuruyordu. Çünkü veriler ille de bir veritabanında saklanmak zorunda değildi. Bu açıdan bakıldığında Datasource'un varlığı çok katmanlı mimaride de vazgeçilmezdir.

Embarcadero'da Delphi ürün müdürü/mimarı olsaydım derdim ki: "Biz Tool Palette'teki her bileşenin bir de TDBxxx versiyonunu mu yazacağız? Her bileşenin veriyi göstermesi için standart bir mimari oluşturalım". Zaten de öyle yapmışlar.
LiveBindings böyle ortaya çıkmış. Datasource'un yerini de Bindingsource almış; adı ne olursa olsun işlevi aynı: görsel bileşenler ile veriyi bağlamak.

Ancak ihtiyaç "her bileşenin her veriye bağlanabilmesi" ise neden her bileşene bir Datasource eklenmedi? Çünkü burada bir amaç daha olduğunu görüyoruz. LiveBindings sadece vertabanından veriyi bileşen içinde göstermiyor; aynı zamanda bileşenlerin herhangi bir özelliğine de bağlantı yapılabiliyor. Dolayısıyla Datasource kalsaydı yanına bir de DataMapping eklemek gerekecekti. Bunu Object Inspector içinde görecektik ve hangi kaynak alanı bileşenin hangi özelliğine bağlayacağımız bir ekran açılacaktı. TGrid Field Editor gibi düşünün.

Bunun yerine -farklılaşmak/katma değer adına- bir ihtiyacı daha gözönüne almış görünüyorlar: DataMapping dediğimiz şeyi görsel bir araç haline getirmişler, adına DataBinding demişler. Bu şekilde de özellikle iş analistleri için görsel bir harita oluşturmuşlar. Aynı nedenden LiveBindings içinde haritayı imaj olarak saklayabiliyorsunuz (dokümantasyon); size veritabanı üzerindeki ERD diyagramı gibi bir görüntü veriyor.

Buraya kadar hoş; benim konuyu açmamdaki temel soru; runtime'da bu BindingSource'un ve ilgili haritanın ne kadar esnek değiştirileceği idi. Biraz daha araştırınca LiveBindings için bir runtime kütüphanesi olduğunu gördüm ama detayını denemedim.
Gördüğüm kadarıyla da bu grupta bu detaylara giren pek yok.

Bileşen sayısı arttıkça LiveBindings haritasının karmaşıklaşacağını ve editörde bir kod göstermemesi nedeniyle debug işlerinin zorlaşacağını görebiliyorum. "Hiç kod yazmadan uygulama geliştirmek" konusu biraz abartılmış gibi geliyor. Ben olsaydım, sonuçta editörde görebileceğim bir kod üretirdim - çünkü bu Delphi'nin temel yaklaşımıdır. Köklerinden kopanın başı dertten kurtulmaz.

Verdiğiniz kod örneğini anladım ama naçizane görüşüm -akademik değerini kabul etmekle birlikte- bunun tekerleği yeniden keşmetmek oldığu görüşünde. OOP kullanarak zilyon iş yapabiliriz ancak ticari uygulamalara gelince hız, üretkenlik, esneklik, maliyet çok önemli faktörler. Bu yüzden Delphi'nin çok zengin bir kütüphanesi var ve mümkün olduğunca hazır bileşenleri kullanmak mantıklı (zaten lisansın pahalılığı bu şekilde açıklanıyor). Standart uygulama geliştirmede OOP kullanacağım hiçbir sıkıştığım durum olmadı. "Rocket science" yapmıyoruz; uygulamaların %99'u bir yerden veriyi alıp işleyip başka bir yere yazıyor. Derseniz ki "ben sıfırdan çok farklı bir şey yapacağım ve eldekiler yetmiyor"; tabii ki OOP esnekliği her zaman var. Ama naçizane görüşüm; OOP'nin daha çok bileşen geliştirenler ve Delphi kütüphanesinin geliştirilmesi için kullanılıyor olması daha değerli.

Dolayısıyla benim yaklaşımım mevcut kütüphaneyi ve bileşenleri kullanmak olur. Daha az kodlama zamanı, daha fazla üretkenlik.

Mesela sunucu tarafında (DataSnap veya başa bir şey) veriyi çekip REST service halinde bir TRestClient'a oradan da TRestResponse/TRestResponseDataSetAdapter kullanarak veriyi bir şekilde ekranda kullanmak varken niye custom object kodlayalım ki?
Datasnap pahalı; zaten benim kullandığım Professional edition'da göremedim. sunucu linux olacağı için; maliyetten kaçmak adına; orada npm vs. gibi bir şeyle REST service yazmak mantıklı geliyor.

Madde #2:

Bir developer eskisi, iş analisti, çözüm mimarı, kurumsal mimar, danışman, proje/program müdürü ve bütün bunların yanında yürüttüğüm proje yönetim ofisinin müdürü olarak naçizane tavsiyem:

Kullandıkları teknoloji/dil ne olursa olsun tüm programcıların (developer) ve adayların kendilerine "ben ne yapıyorum ve doğrusunu mu yapıyorum" diye sormalarıdır. Unutmayalım ki içinde bulunduğumuz BT endüstrisinde -bütün büyük sektörlerde olduğu gibi- bir çok pazarlama taktikleri uygulanmaktadır. Bu taktiklerin kurbanı olmamak için sadece teknolojinin kendisine odaklanmak yetmez; biraz da bütüne bakmak gerekir. Bu aynı zamanda kariyer basamaklarını tırmanmak için önemlidir.

Atatürk, "Türk mileti zekidir, çalışkandır" demişti. Pek fazla insanın üzerinde düşündüğünü sanmıyorum ama "Türk milleti akıllıdır" dememişti (bir sebebi vardı). Programcılarımızın zeki, pratik ve çalışkan oldukları konusunda hiçbir kuşku yok; ama "akıl" konusunda sürekli çalışmak gerekir. Zeka, aklın önkoşuldur ama yeterli değildir. Akıl için bilgi ve mantık gerekir. Umarım doğru mimarilerin ve yaklaşımların ne olduğunu bilmek için sadece Delphi öğrenmenin yeterli olmadığını anlayıp aynı yanlışlara düşülmez.

Bu konuda farkındalık yaratmak adına da BTG grubuna çok görev düştüğü kanısındayım.

Edit: yazıyı tekrar okuyunca içinde emoji eksikliği hissettim. Oysa çok keyif alarak yazdım. Tekrar teşekkür ediyorum :-)
sevgiler,
Cevapla
#12
Merhaba,
Tecrübe ve deneyimlerinize dayalı tespitlerinizi bir makale keyfi ile kudum.
Teşekkürler @behcet.tolga bey.
While true do; Hayat döngüsü, kısır değildir! Yapılan bir yanlış, o döngünün dışına çıkmanızı sağlayacaktır.
WWW
Cevapla
#13
Rica ederim Fesih Bey. Forumunuzu beğendim; ben teşekkür ederim.
selamlar, sevgiler,
Cevapla




Konuyu Okuyanlar: 1 Ziyaretçi