C# ve Delphi ortak bir mimaride: "ya–ya da" yaklaşımı yerine pragmatik entegrasyon

Birçok IT departmanında başlangıç durumu benzerdir: İstikrarlı, süreç odaklı Delphi masaüstü uygulaması kritik süreçleri yürütürken, yeni gereksinimler web, portallar, mobil kullanım ve bulut hizmetleriyle entegrasyon yönünde artıyor. Aynı zamanda servisler, Web-APIs ve kimlik entegrasyonu söz konusu olduğunda birçok şirkette C# tercih ediliyor. Bu nedenle temel soru artık “Delphi veya C#?” değil, aksine: C# ve Delphi in einer gemeinsamen Architektur öyle birleştirmek ki işletim, bakım, veri saklama ve güvenlik yönetilebilir kalsın.

Bu yazı, her şeyin baştan yeniden inşa edilemediği veya edilmemesi gerektiği kurumsal ortamlarda kendini kanıtlamış, uygulamaya uygun mimari ilkeleri açıklar. Odak, masaüstü istemci, servisler, veriler ve arayüzler arasındaki net sorumluluklar üzerinde — ve yürürlükteki süreçleri tehlikeye atmadan modernizasyon adımlarını nasıl düşük riskle planlayacağınız üzerinde.

Neden kurumsal ortamlarda karışık yığınlar normaldir

Büyüyerek oluşan dijital kurumsal çözümler nadiren sıfırdan ortaya çıkar. Delphi uygulamaları genellikle yıllar boyunca, iş süreçlerine yakın şekilde genişletildi; kapsamlı veri mantığı ve özel durumlara dair derin uzmanlık içerir. Eş zamanlı olarak yeni gereksinimler doğdu: Self-Service-Portale, otomatikleştirilmiş veri alışverişleri, DMS/CRM/ERP entegrasyonu, çoklu müşteri desteği (Mandantenfähigkeit), artan denetlenebilirlik veya Single Sign-on.

Bu bağlamda C# genellikle web ve servis ekosistemlerinde avantaj sağlar: geniş hosting seçenekleri, standardize edilmiş ara katman (middleware), kimlik sağlayıcılarla iyi entegrasyon ve Web-API’ler için oturmuş kalıplar. Delphi ise performanslı Windows-masaüstü istemcileri, uzun vadeli bakımı yapılan VCL uygulamaları veya belirli çoklu platform istemcileri (ör. FMX üzerinden) söz konusu olduğunda güçlü kalır.

Bu karışım bu nedenle bir “istisna” değil, yatırım koruması ve modernizasyon baskısına gerçekçi bir yanıttır. Kritik olan, ortak işletmenin sürekli bir şantiye haline gelmemesidir.

Mimari ilke: teknoloji sınırları yerine net katmanlar

İki teknoloji bir araya geldiğinde, ayrımı teknolojiye göre organize etmek caziptir (“Her şey Delphi eski, her şey C# yeni”). Teknik olarak bu genellikle kısa vadede çalışır, ancak uzun vadede sürtüşmeye yol açar: yinelenen iş kuralları, belirsiz sorumluluklar ve zor yeniden üretilebilen hatalar.

Bunun yerine pratikte işe yarayan yaklaşım, genellikle Layer-3 Architektur olarak uygulanan görev bazlı katmanlamadır: Sunum (UI), Alan/Domün (iş mantığı) ve Altyapı (veri erişimi, dış sistemler). Önemli olan ders kitaplarındaki modelden çok günlük hayattaki etkisidir: Veri, doğrulama ve iş akışlarıyla ilgili kararlar tek bir yerde alınır ve kararlı arayüzler üzerinden sunulur.

Karışık bir mimaride bu pratikte şunu ifade eder: Delphi hâlen bir UI bileşeni (veya belirli iş akışlarını) sağlayabilir; aynı zamanda C# Services bir alan/doman katmanını kapsülleyebilir — veya tersi. Önemli olan, katmanlar arasındaki sınırın teknik olarak temiz ve test edilebilir olmasıdır.

C# und Delphi in einer gemeinsamen Architektur: drei bewährte Integrationsmuster

Delphi ile C# arasındaki entegrasyon için tek bir doğru yol yoktur. İyi kararlar işletme, güvenlik gereksinimleri, gecikme, veri hacmi ve sürüm döngülerine göre belirlenir. Pratikte üç desen öne çıkmıştır.

1) HTTP/REST üzerinden servis yönelimi — standart entegrasyon

İşletim ve sürekli geliştirme açısından genellikle en dayanıklı yaklaşım REST-API’leri (HTTP tabanlı arayüzler) üzerinden entegrasyondur. Delphi-istemcileri C# veya Delphi servislerini çağırır; C# portalları aynı uç noktaları kullanır. Bu gevşek bağlama sürümlerin planlanmasını kolaylaştırır: API geriye dönük uyumlu kaldığı sürece istemci güncellemesi zorunlu değildir.

Profesyonel bir uygulama gereklidir: zaman aşımı politikaları, yeniden denemeler, idempotentlik (yan etki oluşturmayan tekrarlanan istekler), açık hata kodları ve bir sürümlendirme stratejisi. Yönetim ve işletim açısından ayrıca önemlidir: tutarlı loglar, izlenebilir Request-ID’ler ve iyi ölçülebilen yanıt süreleri.

2) Ortak veritabanı: sadece net kurallarla

Delphi ve C# tarafından ortak bir veritabanına doğrudan erişim cazip görünebilir çünkü başlangıçta hızlıdır. Uzun vadede ise her iki tarafın da aynı tabloları doğrudan yazması risklidir. Nedeni: iş kuralları trigger’lara, stored procedure’lara veya „istemcinin bir yerinde“ taşınır. Bu durum hata tespiti ve denetimleri zorlaştırır.

Ortak bir veritabanı kaçınılmazsa (ör. geçiş dönemlerinde), net kurallar yardımcı olur:

• Yazma erişimlerini merkezileştirin: bir sistem belirli varlıklar için System of Record olmalıdır.
• Sözleşmeler tanımlayın: doğrudan tablo erişimi yerine View’lar veya API’ler üzerinden stabil bir okuma katmanı sağlayın.
• Migrasyon pencereleri planlayın: veritabanı değişikliklerini her zaman geriye dönük uyumlu şekilde dağıtın (ör. yeni sütunları önce isteğe bağlı ekleyin).

Teknik olarak veritabanı bu senaryoda bir altyapı bileşenidir, entegrasyon bu rolü taşımaz.

3) Messaging/Events für asenkron süreçler

Bağımsız iş akışları (ör. içe aktarma işleri, bildirimler, son işlem aşamaları, arayüz işleri) için asenkron bir model uygundur: bir sistem olayları yayınlar, başka bir sistem bunları işler. Bu doğrudan bağımlılıkları azaltır ve yük piklerini stabilize eder.

BT yöneticileri ve adminler için burada önemli olanlar: izleme (kuyruk uzunlukları), dead-letter kavramları (başarısız mesajlar), yeniden başlatma/düzeltme davranışı ve açık iş idempotentliği. Events, temiz temel veri yönetiminin yerine geçmez, ancak sağlam süreç zincirleri için etkili bir araçtır.

Veri sözleşmeleri ve uyumluluk: hafife alınan çekirdek

Entegrasyon deseninden bağımsız olarak stabiliteyi belirleyen unsur veri sözleşmelerinin kalitesidir. Bir veri sözleşmesi alanların, tiplerin, zorunlu/isteğe bağlı durumun ve semantiğin bağlayıcı tanımıdır. REST-API’lerinde bu tipik olarak JSON formatındadır; önemli olan „JSON’un kendisi“ değil, değişikliklerle ilgili disiplindir.

İşletimi gözle görülür şekilde kolaylaştıran yerleşik kurallar:

• Bozmak yerine genişletin: yeni alanlar ekleyin, mevcut alanları önce sağlamaya devam edin.
• Alan semantiğini belgeleyin: sadece string demek yerine örn. ISO-tarih, saat dilimi, kabul edilebilir durumlar gibi açıklamalar sağlayın.
• Enum değerlerine toleranslı yaklaşın: istemciler bilinmeyen değerlerle çalışmaya devam edebilmeli (forward-compatibility).
• API sürümlendirmesini bilinçli kullanın: her sürüm için yeni bir versiyon gerekmez; ancak geriye dönük uyumsuz değişiklikler kesin olarak izole edilmelidir.

Bu noktalar özellikle Delphi-masaüstü istemcileri web servisleri kadar sık güncellenemiyorsa önem kazanır.

Kimlik Doğrulama ve Yetkilendirme: ortak bir güvenlik modeli

Karma mimariler nadiren „teknik“ yüzünden başarısız olur; daha sık nedensiz güvenlik uygulamalarından kaynaklanır. Şirketler için önemli olan: Kim neye izinli? Bu nasıl doğrulanıyor? Nasıl denetleniyor? Ortak bir model, çift kullanıcı yönetimini ve çelişen rollerin önüne geçer.

Pratikte bu, merkezi bir kimlik katmanına götürür: örneğin SAML 2.0 (federe Single Sign-on, genellikle kurumsal ortamlarda) veya OpenID Connect (OAuth2 tabanlı, modern Web-API’ler için sık kullanılır). C#-Servisler genellikle doğrudan bir Identity Provider’a bağlanabilir; Delphi-istemciler token alabilir ve API çağrılarına ekleyebilir. Önemli olan, masaüstü uygulamalarının veri tabanı erişimi üzerinden „özel haklara“ sahip olmamasıdır.

Yöneticiler için merkezî:

• Token yaşam süreleri ve yenileme stratejisi (istemcilerin kararlı çalışması ve aynı zamanda güvenli olması için)
• Servisler arası kimlik doğrulama iç iletişim için (ör. mTLS veya imzalanmış token’lar)
• Asgari ayrıcalık (Least Privilege): roller ve izinler çok kaba sınırlarla tanımlanmamalı
• Denetim günlükleri: güvenlikle ilgili işlemlerin izlenebilir şekilde kaydedilmesi

İşletme konseptleri: Windows- ve Linux-Servisleri, IIS ve günlük süreçler

Bir mimari, işletilebilir olmadıkça şirket içinde „iyi“ sayılmaz: güncellemeler planlanabilir, hatalar izlenebilir, yük kontrol edilebilir olmalı. Karma ortamlarda en yaygın işletme yaklaşımları şunlardır:

• Windows- ve Linux-Services: arka plan işleri, entegrasyon çalışmaları, worker süreçleri için uygundur; klasik Windows sunucu işletim modellerine iyi entegre olur.
• Windows- ve Linux-Services/Daemon: konteynerize veya VM tabanlı işletme modelleri için mantıklıdır; sürekli çalışmada genellikle stabil olup systemd üzerinden iyi otomasyona olanak verir.
• Microsoft IIS: Windows-odaklı ortamlarda Web uygulamaları ve reverse-proxy senaryoları için yerleşik bir hosting çözümüdür.

Önemli olan, Delphi- ve C#-bileşenlerinin benzer işletme standartlarını karşılamasıdır: tutarlı Health-Endpoint’ler (canlılık kontrolleri), tanımlı zaman aşımı süreleri, sınırlı kaynak kullanımı ve net bir dağıtım ile geri alma prosedürü. Bu, „teknolojiye özel“ istisnai muameleleri azaltır.

Logging, Tracing ve Metrikler: ortak bir Observability seviyesi

İki teknoloji yığını olduğunda uçtan uca teşhis zincirleri kritik öneme sahiptir. Tipik bir sorun: Delphi-istemci „Kaydetme sırasında hata“ bildirir, C#-servis bir zaman aşımı yaşar, veri tabanı kilit raporlar — bunların ortak bir bağlamı yoktur.

Pratikte işe yarayanlar:

• Korelasyon-ID’leri her istek için (Client → API → DB), böylece loglar birleştirilebilir.
• Yapılandırılmış logging (anahtar/değer, saf metin satırları yerine), sonradan filtrelemeyi kolaylaştırmak için.
• Metrikler gecikme, hata oranları, kuyruk uzunlukları ve kaynak kullanımına ilişkin.
• Hata sınıflandırması: işsel hatalar (doğrulama) teknik hatalardan (zaman aşımı, ağ) ayrı tutulmalı.

Bu temeller, pratikte „doğru dil“ üzerine yapılan her tartışmadan daha fazla zaman kazandırır.

Veri erişimi ve göç: BDE-değişimi, FireDAC ve modern veritabanları

Delphi ortamlarında veri erişimi tarihsel olarak önemli bir rol oynar. Borland Database Engine (BDE) gibi eski erişim yolları hâlâ kullanıldığında ek baskılar ortaya çıkar: işletim sistemi güncellemeleri, 64 bit geçişleri, sürücü bulunabilirliği, güvenlik gereksinimleri. Bir BDE-Ablösung sadece modernizasyon değil, aynı zamanda risk azaltma adımıdır.

Tipik olarak BDE-Ablosung mit nativer Anbindung (yerel bağlantılı modern bir veri erişim katmanı Delphi içinde) ve işletmesi yönetilebilir bir veritabanı (ör. PostgreSQL, SQL Server, MariaDB) tercih edilir. Ortak bir Delphi/C# mimarisi için iki husus önemlidir:

• Transaktionsgrenzen: İşlemleri kim başlatıyor/commit ediyor ve paralel yazma erişimleri nasıl düzenleniyor?
• Locking- und Isolation-Strategie: masaüstü iş akışları ile servislerin birbirini bloke etmemesi için.

Göçlerde kademeli bir planlama işe yarar: önce sürücü ve erişim katmanını modernize edin, sonra veri modelini konsolide edin, ardından entegrasyon arayüzlerini stabil hale getirin. Böylece hata kaynakları izole edilebilir ve roll-backler gerçekçi olur.

Sürüm Yönetimi: farklı güncelleme döngülerini aynı çatı altında toplamak

Sık rastlanan bir gerilim alanı güncelleme sıklığıdır: Web servisleri daha sık dağıtılabilirken, masaüstü istemciler genellikle daha seyrek (dağıtım penceresi, kullanıcı iletişimi, paketleme). Ortak bir mimari bu asimetrileri hesaba katmalıdır.

Pratik sonuçlar:

• API-Abwärtskompatibilität zorunluluktur, tercih meselesi değil.
• Feature Flag’ler (işlevsel anahtarlar), yeni özellikleri sunucu tarafında kontrollü olarak etkinleştirmeye yardımcı olur.
• Şema migrasyonları aşamalı olmalıdır: önce veritabanını genişletin, sonra servisi kullanın, ardından istemciyi güncelleyin.
• Açık kullanımdan kaldırma: Eski uç noktalar veya alanlar sadece tanımlanmış bir süre sonra kaldırılmalıdır.

Özellikle düzenlemelere tabi ortamlarda bu kuralların mimari rehber ilkeleri olarak yazılı hale getirilmesi önemlidir; böylece kararlar proje bazında yeniden icat edilmez.

Tipik takılma noktaları ve bunların sistematik olarak nasıl önleneceği

Operasyon perspektifinden, karışık Delphi/C# ortamlarındaki en sık görülen sorunlar öngörülebilirdir. Bunları erken ele alırsanız uzun vadeli maliyetler belirgin şekilde düşer.

Takılma Noktası 1: çiftlenmiş iş mantığı

Delphi istemcisi ile C# servisi aynı kuralları farklı şekilde uygularsa „hayalet hatalar“ oluşur: Bir süreç UI’da çalışırken API importunda başarısız olur. Karşı önlem: kuralları domain katmanında merkezi hale getirmek (servis) veya kuralları iş açısından net şekilde tahsis etmek; ayrıca tekdüze ve açık doğrulama yanıtları sağlamak.

Takılma Noktası 2: UI geçici çözümleri yerine temiz arayüzler

„Hemen bir veritabanı alanı yazmak“ tek seferlikte zararsız görünebilir, fakat logging, kimlik doğrulama ve versiyonlama olmayan gölge arayüzler üretir. Daha iyi olan: başlangıçta daha fazla disiplin gerektirse bile tanımlı uç noktalar üzerinden tutarlı bir şekilde gitmektir.

Takılma Noktası 3: işletmede belirsiz sorumluluklar

Hangi ekibin hangi hizmetten, hangi logdan ve hangi işletme parametresinden sorumlu olduğu net değilse, hata araştırması ping-pong’a dönüşür. Pratikte bir servis haritası (hangi hizmet, hangi bağımlılıklar, hangi portlar, dahili SLA’lar) ve sık görülen arızalar için standart runbook’lar yardımcı olur.

Tuzak 4: güvenlik tutarlılığı eksikliği

SSO’lu bir portal varken yerel yönetici hesaplarına sahip bir masaüstü istemcisi birçok denetimde sorun yaratır. Ortak bir kimlik ve rol modeli riski ve destek yükünü azaltır.

Karar yardımı: Delphi’de ne kalmalı, C#’ye ne gitmeli?

Mantıklı ayrım ideolojiden ziyade süreç yakınlığı ve işletme gereksinimlerine bağlıdır. Mimari ve işletme bakışından yol gösterici olarak:

• Delphi genellikle uygundur für: mevcut Windows-masaüstü istemcileri (VCL), çok hızlı yanıt veren UI iş akışları, çevrimdışıya yakın senaryolar, oluşmuş arayüzlerin uzun vadeli bakımı.
• C# genellikle uygundur für: merkezi REST-API’ler, ERP/DMS/CRM entegrasyon servisleri, kimlik odaklı bileşenler, yüksek değişiklik sıklığına sahip portallar ve backend süreçleri.
• Bilinçli karar verin: Birden fazla frontend (masaüstü, portal, import işleri) varsa veri mantığı ve doğrulama „istemci“de yer almamalıdır.

Önemli: Amaç „her şeyi C#’ye taşımak“ değil, modernizasyon adımlarının planlanabildiği ve şirket süreçlerinin istikrarlı çalıştığı güvenilir bir genel mimari oluşturmaktır.

Modernizasyon yolu: uygulamadan sisteme adım adım

Pratikte ortak bir mimari sıklıkla bir geçiştir, ancak uzun sürer. Gerçekçi bir modernizasyon yolu yüksek riskli büyük projeleri önler ve ölçülebilir ara hedeflere dayanır:

1. Arayüzleri istikrara kavuşturun: REST-API’yi fonksiyonel bir sınır olarak devreye alın, içerde her şey „güzel“ olmasa bile.
2. Veri erişimini modernize edin: BDE-yerine geçirme, sürücüler, 64‑Bit desteği, tutarlı işlemler.
3. Kimlik yönetimini merkezileştirin: Tüm erişim yolları için SSO ve rol modeli.
4. İşletmeyi standartlaştırın: Logging/Monitoring/Health, net dağıtımlar, yeniden üretilebilir ortamlar.
5. Fonksiyonel modülleri ayrıştırın: Özellikle değişime açık parçaları servislere taşıyın, UI’yı kademeli olarak sadeleştirin.

Bu sıra dogmatik değildir, ancak genellikle bağımlılıkları en aza indirir: Stabil arayüzler ve işletme konsepti olmadan her ek değişiklik daha pahalıya mal olur.

Sonuç: Entegrasyon bir mimari görevdir, dil meselesi değildir

Delphi ile C# arasında sürdürülebilir bir kombinasyon „köprü kütüphaneler“ ile değil, açık işlevsel sınırlar, temiz veri sözleşmeleri ve izleme, güvenlik ile sürüm yönetimini ciddiye alan bir işletme konsepti ile oluşur. Eğer C# ve Delphi ortak bir mimaride sorumluluklar doğrultusunda bilinçli şekilde birlikte çalışırsa, şirketler en çok şunu kazanır: süreç kopması olmadan modernizasyon. Delphi kararlı masaüstü iş akışlarını güvenilir şekilde taşımaya devam edebilirken, C#-servisleri entegrasyon, Web-API’ler ve portalları merkezi platform işlevleri olarak sağlar.

Eğer mevcut Delphi ortamınızı adım adım modernize etmek veya C#-servislerini temiz şekilde entegre etmek istiyorsanız, arayüzler, veriler, işletme ve güvenlik açısından yapılacak bir mimari inceleme güvenilir kararlar için en hızlı yoldur. Daha fazlası için doğrudan iletişim:

İşlevsel bağlamda, Delphi modernizasyon ve REST-API, entegrasyonlar, veri akışları ve ileriye dönük geliştirmelerin uyumlu çalışması gerektiğinde mevcut yazılımlar için önemli bir rol oynar.

Proje veya modernizasyon girişiminizi Net-Base ile görüşün.