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

Çoğu BT departmanında başlangıç durumu benzerdir: İş süreçlerine yakın, kararlı bir 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 hizmetler, Web-API’ler ve kimlik entegrasyonu söz konusu olduğunda birçok kuruluşta C# yerleşik hale gelmiştir. Bu nedenle merkezi soru artık „Delphi yoksa C# mi?“ değil, aksine: C# ve Delphi’i ortak bir mimaride öyle bir şekilde birleştirmek ki işletim, bakım, veri yönetimi ve güvenlik kontrol altında kalsın.

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

Kurumsal ortamlarda karma yığınların normal olmasının nedeni

Gelişen dijital kurumsal çözümler nadiren sıfırdan ortaya çıkar. Delphi uygulamaları genellikle yıllar içinde, iş süreçlerine yakın olarak, kapsamlı veri mantığı ve özel durumlara dair derin bilgiyle genişletilmiştir. Paralel olarak yeni gereksinimler doğmuştur: self-service portallar, otomatik veri değişimleri, DMS/CRM/ERP entegrasyonları, çoklu kiracı desteği, daha güçlü denetlenebilirlik veya Single Sign-on.

Bu bağlamda C# sıklıkla web ve servis ekosistemlerinde avantaj sağlar: geniş hosting yelpazesi, standartlaştırılmış middleware, kimlik sağlayıcılarla iyi entegrasyon ve Web-API’ler için yerleşik desenler. Delphi ise performanslı Windows-masaüstü istemciler, uzun vadeli bakımı yapılan VCL uygulamaları veya belirli çoklu platform istemcileri (ör. FMX aracılığıyla) 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. Belirleyici olan, ortak işletmenin sürekli bir şantiye haline gelmemesidir.

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

İki dil bir araya geldiğinde ayrımı teknoloji doğrultusunda organize etme eğilimi yüksektir („Her şey Delphi eskidir, her şey C# yenidir“). Teknik olarak bu çoğunlukla kısa vadede çalışır, ancak uzun vadede sürtüşmeye yol açar: iş kurallarının iki kez uygulanması, belirsiz sorumluluklar ve zor tekrarlanabilir hatalar.

Bunun yerine kendini kanıtlamış bir işlevsel katmanlama genellikle işe yarar; sıklıkla Layer-3 Architektur olarak uygulanır: Sunum (UI), Alan (iş mantığı) ve Altyapı (veri erişimi, dış sistemler). Önemli olan ders kitabı modeli değil, günlük hayattaki somut etkisidir: veri, doğrulamalar ve iş akışlarıyla ilgili kararlar tek bir yerde alınır ve stabil arayüzler üzerinden sunulur.

Karma bir mimaride bunun pratik karşılığı şudur: Delphi hâlâ bir UI bileşeni (veya belirli iş akışları) sağlayabilirken, C# servisleri bir iş alanı katmanını kapsayabilir — veya tersi. Önemli olan, katmanlar arasındaki sınırın teknik olarak temiz ve test edilebilir olmasıdır.

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

Für die Kopplung von Delphi und C# gibt es nicht „den einen“ richtigen Weg. Gute Entscheidungen orientieren sich an Betrieb, Sicherheitsanforderungen, Latenz, Datenvolumen und Release-Zyklen. In der Praxis haben sich drei Muster herausgebildet.

1) Service-Orientierung über HTTP/REST als Standardkopplung

Am robustesten für Betrieb und Weiterentwicklung ist häufig eine Kopplung über REST-APIs (HTTP-basierte Schnittstellen). Delphi-Clients rufen C#- oder Delphi-Services auf; C#-Portale nutzen dieselben Endpunkte. Diese Entkopplung macht Releases planbarer: Ein Client-Update ist nicht zwingend nötig, wenn die API abwärtskompatibel bleibt.

Wichtig ist dabei die professionelle Ausgestaltung: Timeouts, Retries, Idempotenz (wiederholbare Requests ohne Nebenwirkungen), klare Fehlercodes und eine Versionierungsstrategie. Für Administration und Betrieb zählt außerdem: einheitliche Logs, nachvollziehbare Request-IDs und gut messbare Antwortzeiten.

2) Gemeinsame Datenbank: nur mit klaren Spielregeln

Ein gemeinsamer Datenbankzugriff von Delphi und C# wirkt verlockend, weil er anfangs schnell ist. Langfristig ist er aber risikoreich, wenn beide Welten direkt auf denselben Tabellenbestand schreiben. Der Grund: Geschäftsregeln verlagern sich in Trigger, Stored Procedures oder in „irgendwo im Client“. Das erschwert Fehleranalyse und Audits.

Wenn eine gemeinsame Datenbank unvermeidbar ist (z. B. in Übergangsphasen), helfen klare Regeln:

• Schreibzugriffe zentralisieren: ein System ist „System of Record“ für bestimmte Entitäten.
• Verträge definieren: Views oder APIs als stabile Leseschicht statt direkter Tabellenzugriffe.
• Migrationsfenster planen: Datenbankänderungen immer rückwärtskompatibel ausrollen (z. B. neue Spalten zuerst optional).

Technisch ist die Datenbank dann eine Infrastrukturkomponente, nicht der Integrationsbus.

3) Messaging/Events für asynchrone Prozesse

Für entkoppelte Abläufe (z. B. Importläufe, Benachrichtigungen, Nachverarbeitung, Schnittstellen-Jobs) ist ein asynchrones Modell sinnvoll: Ein System publiziert Ereignisse, ein anderes verarbeitet sie. Das reduziert direkte Abhängigkeiten und stabilisiert Lastspitzen.

Für IT-Leitung und Admins ist hier wichtig: Monitoring (Queue-Längen), Dead-Letter-Konzepte (fehlgeschlagene Nachrichten), Wiederanlaufverhalten und klare fachliche Idempotenz. Events sind kein Ersatz für saubere Stammdatenführung, aber ein gutes Werkzeug für robuste Prozessketten.

Datenverträge und Kompatibilität: der unterschätzte Kern

Unabhängig vom Integrationsmuster entscheidet die Qualität der Datenverträge über Stabilität. Ein Datenvertrag ist die verbindliche Beschreibung von Feldern, Typen, Pflicht/Optional und Semantik. In REST-APIs ist das typischerweise JSON; wichtig ist dabei nicht „JSON an sich“, sondern die Disziplin im Umgang mit Änderungen.

Bewährte Regeln, die den Betrieb spürbar vereinfachen:

• Erweitern statt brechen: neue Felder hinzufügen, alte zunächst weiter liefern.
• Feldsemantik dokumentieren: nicht nur „string“, sondern z. B. ISO-Datum, Zeitzone, zulässige Zustände.
• Enum-Werte tolerant behandeln: Clients müssen unbekannte Werte überleben (Forward-Compatibility).
• API-Versionierung bewusst einsetzen: nicht jedes Release braucht eine neue Version; aber Breaking Changes müssen eindeutig gekapselt werden.

Diese Punkte sind besonders wichtig, wenn Delphi-Desktop-Clients nicht so häufig aktualisiert werden können wie Web-Services.

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

Karışık mimariler nadiren „Teknik“ nedeniyle başarısız olur; daha sık tutarsız güvenlik uygulamaları nedeniyle başarısız olurlar. Kurumlar için önemli olan: Kim neye yetkili? Bu nasıl doğrulanıyor? Nasıl denetleniyor? Ortak bir model, çift kullanıcı yönetimi ve çelişen rollerin önüne geçer.

Pratikte bunun sonucu merkezi bir kimlik katmanı olur: örneğin SAML 2.0 (federe Tek Oturum Açma, genellikle kurumsal ortamlarda) veya OpenID Connect (OAuth2 tabanlı, modern Web-API’ler için sık kullanılır). C#-servisleri genellikle doğrudan bir Identity Provider’a bağlanabilir; Delphi-istemciler token alıp API çağrılarıyla iletebilir. Önemli olan, masaüstü uygulamalarının da veritabanı erişimiyle „özel“ ayrıcalıklar elde etmemesidir.

Yöneticiler için merkezi olarak:

• Token ömürleri 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 imzalı tokenlar)
• En az ayrıcalık: Roller ve izinler gereğinden geniş verilmemeli
• Denetim kayıtları: güvenlikle ilgili işlemlerin izlenebilir şekilde kaydedilmesi

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

Bir mimari, kurum içinde ancak işletilebilir ise „iyi“ sayılır: Güncellemeler planlanabilir, hatalar yerel olarak bulunabilir, yük kontrol edilebilir olmalı. Karışık ortamlarda en yaygın işletim çeşitleri şunlardır:

• Windows- ve Linux-Servisler: arka plan görevleri, ara yüz iş akışları, worker işlemleri için uygun; geleneksel Windows sunucu işletim modellerine iyi entegre olur.
• Windows- ve Linux-Servisler/Daemon: konteyner veya VM tabanlı işletim modelleri için mantıklı; uzun süreli çalışmada genellikle stabildir, systemd üzerinden iyi otomasyon imkânı sağlar.
• Microsoft IIS: Windows-merkezli ortamlarda web uygulamaları ve ters-proxy senaryoları için yerleşik bir barındırma çözümüdür.

Önemli olan, Delphi- ve C#-bileşenlerinin benzer işletim standartlarını karşılamasıdır: tutarlı health-endpoint’ler (canlılık kontrolleri), tanımlı zaman aşımı değerleri, sınırlı kaynak kullanımı ve net bir dağıtım ile geri alma (rollback) prosedürü. Bu, „teknolojiye özgü“ ayrıcalıklı muamelenin azalmasını sağlar.

Günlükleme, İzleme ve Metrikler: ortak bir gözlemlenebilirlik seviyesi

İki teknoloji yığını olduğunda uçtan uca tanı zincirleri kritik öneme sahiptir. Tipik bir sorun: Delphi-istemci „kaydetme hatası“ raporlar, C#-servisinde zaman aşımı olur, veritabanı kilit olduğunu bildirir — bunlar ortak bir bağlam olmadan bir araya getirilemez.

Pratikte faydalı olan uygulamalar:

• Korelasyon ID’leri her istek için (İstemci → API → DB), böylece loglar birleştirilebilir.
• Yapılandırılmış günlükleme (anahtar/değer biçiminde, düz metin satırları yerine) ileride filtreleme yapabilmek için.
• Metrikler gecikme, hata oranları, kuyruk uzunlukları ve kaynak kullanımı için.
• Hata sınıflandırması: İş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-ikamesi, FireDAC ve modern veritabanları

Delphi envanterlerinde veri erişimi tarihsel olarak önemli bir rol oynar. Borland Database Engine (BDE) gibi eski erişim yollarının hâlâ kullanıldığı yerlerde ilave baskı oluşur: işletim sistemi güncellemeleri, 64‑bit geçişleri, sürücü erişilebilirliği, güvenlik gereksinimleri. Bir BDE-ikamesi bu durumda yalnızca modernizasyon değil, aynı zamanda risk azaltmadır.

Tipik olarak geçiş, BDE-ikamesi ile yerel bağlantı (Delphi içinde modern bir veri erişim katmanı) ve işletme açısından iyi yönetilebilir bir veritabanı kombinasyonu şeklinde yapılır (örn. PostgreSQL, SQL Server, MariaDB). Ortak bir Delphi/C# mimarisi için iki nokta özellikle önemlidir:

• İşlem sınırları: İşlemleri kim başlatır/commit eder ve paralel yazma erişimleri nasıl düzenlenir?
• Kilitleme ve izolasyon stratejisi: masaüstü iş akışları ile servislerin birbirini engellememesi için.

Göçlerde aşamalı bir planlama işe yarar: önce sürücü ve erişim katmanını modernize etmek, sonra veri modelini konsolide etmek, ardından entegrasyon arayüzlerini stabilize etmek. Bu şekilde hata kaynakları izole edilebilir ve geri dönüşler (rollbacks) gerçekçi olur.

Sürüm yönetimi: farklı güncelleme döngülerini uyumlu hale getirmek

Sürekli tekrar eden bir gerilim alanı güncelleme sıklığıdır: Web servisler daha sık yayımlanabilirken, masaüstü istemciler genellikle daha seyrek güncellenir (yayın pencereleri, kullanıcı iletişimi, paketleme). Ortak bir mimari bu asimetrinin hesabını vermelidir.

Pratik sonuçlar:

• API geriye dönük uyumluluk zorunludur, tercihe bağlı değildir.
• Feature Flags (fonksiyonel anahtarlar), yeni özellikleri sunucu tarafında kontrollü olarak etkinleştirmeye yardımcı olur.
• Şema göçleri aşamalar halinde yürütülmelidir: önce veritabanı genişletilir, sonra servis kullanır, ardından istemci takip eder.
• Net bir kullanım dışı bırakma: Eski uç noktalar veya alanlar yalnızca tanımlanmış bir süre sonra kaldırılmalıdır.

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

Tipik tökezleme noktaları und bunlardan nasıl sistematik olarak kaçınılır

Operasyon açısından, karma Delphi/C# ortamlarındaki en yaygın problemler iyi öngörülebilir. Bunlara erken müdahale edildiğinde uzun vadeli maliyetler belirgin şekilde düşer.

Tökezleme 1: çiftlenen iş mantığı

Eğer Delphi istemcisi ile C# servisi aynı kuralları farklı şekilde uygularsa „hayalet hatalar“ ortaya çıkar: Bir süreç UI’da çalışırken API aktarımında başarısız olur. Çözüm: kuralları domain/alan katmanında merkezileştirmek (servis) ya da fonksiyonel olarak net şekilde atamak; bu, açık ve belirgin validasyon yanıtlarını da kapsamalıdır.

Tökezleme 2: UI geçici çözümleri yerine temiz arayüzler

„Hızlıca bir veritabanı alanı yazmak“ tek başına zararsız görünebilir, ancak logging, kimlik doğrulama ve versiyonlama olmadan gölge arayüzler üretir. Daha doğru olanı: başlangıçta daha fazla disiplin gerektirse bile tanımlanmış uç noktalar üzerinden tutarlı şekilde ilerlemektir.

Tökezleme 3: işletmede belirsiz sorumluluklar

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

Problem 4: güvenlik tutarlılığının eksikliği

SSO’ya sahip bir portal, ancak yerel yönetici hesapları olan 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 desteği: Delphi’de ne kalmalı, C#’ye ne aktarılmalı?

Mantıklı ayrım ideolojiden ziyade süreç yakınlığı ve işletme gereksinimlerine bağlıdır. Mimari ve işletme bakış açısından bir yönlendirme:

• Delphi genellikle iyi uygundur için: mevcut Windows-masaüstü istemcileri (VCL), çok hızlı tepki gerektiren UI iş akışları, çevrimdışıya yakın senaryolar, zaman içinde gelişmiş arayüzlerin uzun vadeli bakımı.
• C# genellikle iyi uygundur için: merkezi REST-API’leri, ERP/DMS/CRM entegrasyon servisleri, kimlik odaklı bileşenler, portallar ve yüksek değişim sıklığına sahip backend süreçleri.
• Bilinçli karar verin: Birden fazla frontend (masaüstü, portal, import işlerinin) varlığında veri mantığı ve doğrulama “istemcide” olmamalıdır.

Önemli: Amaç „her şeyi C#’ye taşımak“ değil, modernizasyon adımlarının planlanabilir olduğu ve kurumsal süreçlerin stabil çalıştığı dayanıklı bir toplam mimari oluşturmaktır.

Modernizasyon yolu: Uygulamadan sisteme kademeli geçiş

Pratikte ortak bir mimari genellikle bir geçiş sürecidir, ama uzun bir süreçtir. Gerçekçi bir modernizasyon yolu yüksek riskli büyük projelerden kaçınır ve ölçülebilir ara hedeflere odaklanır:

1. Arayüzleri stabil hale getirin: REST-API’yi bir iş sınırı olarak tanımlayın, içeride hâlâ her şey “güzel” değilse bile.
2. Veri erişimini modernize edin: BDE’nin yerine geçişi, sürücüler, 64‑Bit yetenek, tutarlı işlemler.
3. Kimlik yönetimini merkezileştirin: Tüm erişim yolları için SSO ve roller modeli.
4. İşletmeyi standartlaştırın: Kayıt/izleme/sağlık kontrolleri, net dağıtımlar, tekrarlanabilir ortamlar.
5. İşlevsel modülleri ayırın: Özellikle değişiklik yoğun parçaları servislere kaydırın, UI’yı kademeli olarak sadeleştirin.

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

Sonuç: Entegrasyon bir mimari konusudur, dil tercihi değil

Dayanıklı bir Delphi ve C# kombinasyonu “köprü kütüphaneler” ile değil, net iş sınırları, temiz veri sözleşmeleri ve izleme, güvenlik ve sürüm yönetimini ciddiye alan bir işletme konseptiyle oluşur. Eğer C# ve Delphi ortak bir mimaride sorumluluklar doğrultusunda bilinçli şekilde birlikte oynarsa, şirketlerin en çok kazandığı şey modernizasyonun süreç kırılması olmadan gerçekleşmesidir. Delphi istikrarlı masaüstü iş akışlarını güvenilir şekilde taşımaya devam edebilirken, C# servisleri entegrasyon, Web-API’ler ve portalları merkezi platform fonksiyonları olarak sağlar.

Mevcut bir Delphi ortamını kademeli olarak modernize etmek veya C# servislerini temiz şekilde entegre etmek istiyorsanız, arayüzler, veri, işletme ve güvenlik odaklı bir mimari incelemesi en hızlı yol olup sağlam kararlar alınmasını sağlar. Bununla ilgili daha fazlası doğrudan görüşmede:

Uzmanlık alanında, entegrasyonlar, veri akışları ve ileriye dönük geliştirme düzgün şekilde birlikte çalışması gerektiğinde, Delphi modernizasyonu ve REST-API’leri mevcut yazılımlar için önemli bir rol oynar.

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