C# a Delphi ve společné architektuře: pragmatická integrace místo buď‑nebo

V mnoha IT odděleních je výchozí situace podobná: stabilní, procesně blízká Delphi-desktopová aplikace nese kritické procesy, zatímco nové požadavky směřují k webu, portálům, mobilnímu použití a integraci s cloudovými službami. Současně je C# v mnoha firmách standardem, pokud jde o služby, webová API a integraci identity. Centrální otázka tedy už není „Delphi oder C#?“, ale: jak kombinovat C# a Delphi v jedné společné architektuře tak, aby provoz, údržba, správa dat a bezpečnost zůstaly zvládnutelné.

Tento článek popisuje prakticky použitelné architekturní principy, které se osvědčily v podnikových prostředích, kde není možné nebo žádoucí vše přestavět. Důraz je na jasných odpovědnostech mezi desktopovým klientem, službami, daty a rozhraními – a na tom, jak plánovat kroky modernizace s nízkým rizikem, aniž by byly ohroženy běžící procesy.

Proč jsou v podnicích smíšené stacky běžné

Rostoucí digitální podniková řešení zřídka vznikají na zelené louce. Delphi-aplikace byly často po mnoho let rozšiřovány, blízko obchodním procesům, s rozsáhlou datovou logikou a hlubokými znalostmi o výjimkách. Současně vznikly nové požadavky: self-service portály, automatizovaná výměna dat, napojení DMS/CRM/ERP, multitenantnost, zvýšená auditovatelnost nebo Single Sign-on.

C# v tomto kontextu často nabízí výhody pro webová a servisní ekosystémy: široké možnosti hostingu, standardizovanou middleware, dobrou integraci do identity providerů a osvědčené vzory pro webová API. Delphi je naopak silná tam, kde jde o výkonné Windows-desktop klienty, dlouhodobě udržované VCL aplikace nebo specifické multiplatformní klienty (např. přes FMX).

Proto tato směs není „Sonderfall“, ale realistickou odpovědí na ochranu investic a tlak na modernizaci. Rozhodující je, aby společný provoz nestal trvalou stavbou.

Zásada architektury: jasné vrstvy místo hranic podle jazyka

Když se potkají dva jazyky, je velké pokušení organizovat separaci podél technologie („Alles Delphi ist Legacy, alles C# ist neu“). Technicky to často funguje krátkodobě, ale dlouhodobě vede k tření: duplicitní obchodní pravidla, nejasné odpovědnosti a těžko reprodukovatelné chyby.

Místo toho se osvědčilo logické vrstvení, často realizované jako Layer-3 architektura: prezentace (UI), doména (obchodní logika) a infrastruktura (přístup k datům, externí systémy). Jde méně o učebnicový model než o konkrétní dopad v praxi: rozhodnutí o datech, validacích a pracovních postupech se přijímají na jednom místě a zpřístupňují se přes stabilní rozhraní.

V praxi to v smíšené architektuře znamená: Delphi může nadále poskytovat UI část (nebo určité pracovní postupy), zatímco C# Services mohou kapslovat obchodní doménovou vrstvu – nebo obráceně. Důležité je, aby hranice mezi vrstvami byla technicky čistá a testovatelná.

C# a Delphi v jedné společné architektuře: tři osvědčené integrační vzory

Pro propojení Delphi a C# neexistuje „jeden“ správný způsob. Dobrá rozhodnutí se řídí provozem, bezpečnostními požadavky, latencí, objemem dat a cykly vydávání. V praxi se vyprofilovaly tři vzory.

1) Orientace na služby přes HTTP/REST jako standardní řešení propojení

Nejrobustnějším řešením pro provoz a další rozvoj je často propojení přes REST-APIs (HTTP‑založená rozhraní). Klienti Delphi volají služby C# nebo Delphi; portály C# používají stejné koncové body. Toto oddělení činí vydání lépe plánovatelným: aktualizace klienta není nutná, pokud API zůstane zpětně kompatibilní.

Důležitá je přitom profesionální implementace: timeouty, retry mechanismy, idempotence (opakovatelná volání bez vedlejších účinků), jasné chybové kódy a strategie verzování. Pro administraci a provoz je dále rozhodující: jednotné logy, sledovatelná ID požadavků a dobře měřitelné doby odezvy.

2) Sdílená databáze: jen s jasnými pravidly

Společný přístup do databáze ze strany Delphi a C# je na první pohled lákavý, protože je rychlý. Z dlouhodobého hlediska je však rizikový, pokud obě strany zapisují přímo do stejného souboru tabulek. Důvod: obchodní pravidla se přesunou do triggerů, uložených procedur nebo „někde v klientovi“. To ztěžuje analýzu chyb a audity.

Pokud je sdílená databáze nevyhnutelná (např. v přechodných fázích), pomohou jasná pravidla:

• Centralizovat zápisy: jeden systém funguje jako „System of Record“ pro konkrétní entity.
• Definovat smlouvy: views nebo API jako stabilní čtecí vrstva místo přímých přístupů do tabulek.
• Plánovat migrační okna: změny v databázi zavádět vždy zpětně kompatibilně (např. nové sloupce nejprve jako volitelné).

Technicky je databáze pak infrastrukturní komponentou, nikoli integrační sběrnicí.

3) Messaging/Events pro asynchronní procesy

Pro odpojené toky (např. importy, notifikace, následné zpracování, rozhraníové joby) je vhodný asynchronní model: jeden systém publikuje události, jiný je zpracovává. To snižuje přímé závislosti a stabilizuje špičky zátěže.

Pro IT vedení a administrátory je zde důležité: monitoring (délky front), koncepty dead‑letter (neúspěšné zprávy), chování při opětovném spuštění a jasná doménová idempotence. Events nejsou náhradou za správné vedení základních dat, ale jsou užitečným nástrojem pro robustní procesní řetězce.

Datové smlouvy a kompatibilita: podceňované jádro

Nezávisle na integračním vzoru rozhoduje o stabilitě kvalita datových smluv. Datová smlouva je závazný popis polí, typů, povinnosti/volitelnosti a sémantiky. V REST-APIs je to typicky JSON; důležité není „JSON samo o sobě“, ale disciplína při zacházení se změnami.

Osvědčená pravidla, která výrazně zjednodušují provoz:

• Rozšiřovat místo porušení: přidávat nová pole, stará pole nejprve nadále poskytovat.
• Dokumentovat sémantiku polí: ne jen „string“, ale např. ISO datum, časové pásmo, povolené stavy.
• Výčtové hodnoty zpracovávat tolerantně: klienti musí přežít neznámé hodnoty (Forward‑Compatibility).
• Verzování API uvážlivě nasazovat: ne každé vydání vyžaduje novou verzi; Breaking Changes však musí být jednoznačně izolovány.

Tato pravidla jsou obzvlášť důležitá, pokud nelze Delphi-desktopové klienty aktualizovat tak často jako webové služby.

Autentizace a autorizace: společný bezpečnostní model

Smíšené architektury selhávají zřídka kvůli „technice“, častěji kvůli nekonzistentní bezpečnosti. Pro podnik je rozhodující: kdo má jaké oprávnění? Jak se to ověřuje? Jak se to audituje? Společný model zabraňuje duplicitní správě uživatelů a konfliktním rolím.

V praxi to vede k centrální vrstvě identity: například přes SAML 2.0 (federované Single Sign-on, běžné v enterprise prostředí) nebo OpenID Connect (postavené na OAuth2, často pro moderní webová API). C#-Services je obvykle možné přímo připojit k Identity Provideru; Delphi-klienti mohou získávat tokeny a zasílat je při API voláních. Důležité je, aby ani desktopové aplikace nezískávaly „výjimková“ práva přímým přístupem do databáze.

Centrálně pro administrátory:

• Doba životnosti tokenů a strategie obnovy (aby klienti běželi stabilně a přitom zůstali bezpeční)
• Service-to-Service Auth pro interní komunikaci (např. mTLS nebo podepsané tokeny)
• Least Privilege: role a oprávnění nedělit příliš hrubě
• Audit-Logs: bezpečnostně relevantní akce zaznamenávat tak, aby byly dohledatelné

Provozní koncepty: Windows- a Linux-Services, IIS a procesy v každodenním provozu

Architektura je v podniku „dobrá“ pouze tehdy, je-li provozovatelná: aktualizace plánovatelné, chyby lokalizovatelné, zátěž ovladatelná. V mixovaných prostředích jsou nejběžnější provozní varianty:

• Windows- und Linux-Services: vhodné pro úlohy na pozadí, běhy rozhraní, workery; dobře integrovatelné do klasických Windows-serverových provozních modelů.
• Windows- und Linux-Services/Daemon: rozumné pro kontejnerizované nebo VM-založené provozní modely; často stabilní v dlouhodobém provozu, dobrá automatizace přes systemd.
• Microsoft IIS: zavedené hostingové řešení pro webové aplikace a reverse-proxy scénáře v prostředích orientovaných na Windows.

Důležité je, aby komponenty Delphi a C# splňovaly podobné provozní standardy: konzistentní Health-Endpoints (indikátory životnosti), definované timeouty, omezená spotřeba prostředků, stejně jako jasné deployment- a rollback-procedury. To snižuje „technologicky specifická“ zvláštní ošetření.

Logging, Tracing und Metriken: ein gemeinsames Observability-Niveau

Právě u dvou technologických stacků jsou průběžné diagnostické řetězce rozhodující. Typický problém: Delphi-klient hlásí „Chyba při ukládání“, C#-service má timeout, databáze hlásí zamykání – bez společného kontextu.

V praxi se osvědčily:

• Korrelations-IDs pro každý požadavek (Client → API → DB), aby bylo možné logy sloučit.
• Strukturované logování (klíč/hodnota místo čistých textových řádků), pro možnost pozdějšího filtrování.
• Metriky pro latenci, chybovost, délky fronty a využití prostředků.
• Klasifikace chyb: Business-chyby (validace) odděleně od technických chyb (timeout, síť).

Tyto základy v praxi ušetří více času než jakákoli debata o „správném jazyce“.

Přístup k datům a migrace: BDE-náhrada, FireDAC a moderní databáze

Ve stávajících nasazeních Delphi má přístup k datům historicky velký význam. Kde jsou ještě v provozu staré způsoby přístupu, jako Borland Database Engine (BDE), vzniká dodatečný tlak: aktualizace operačního systému, přechod na 64‑bit, dostupnost ovladačů, bezpečnostní požadavky. BDE-náhrada pak není jen modernizací, ale snížením rizika.

Typické je přechod na BDE-náhrada s nativním připojením (moderní vrstva přístupu k datům v Delphi), kombinovaný s databází, která je provozně dobře zvládnutelná (např. PostgreSQL, SQL Server, MariaDB). Pro společnou Delphi/C# architekturu jsou přitom důležité dva aspekty:

• Transakční hranice: kdo zahajuje/potvrzuje (commit) transakce a jak se řídí paralelní zápisy?
• Strategie zamykání a izolace: aby se desktopové pracovní postupy a služby navzájem neblokovaly.

Při migracích se osvědčuje postupné plánování: nejprve modernizovat vrstvu ovladačů a přístupu, pak konsolidovat datový model, následně stabilizovat integrační rozhraní. Tím jsou chybové zdroje izolovatelné a rollbacky realistické.

Řízení vydání: sladit odlišné aktualizační cykly

Opakujícím se zdrojem napětí je frekvence aktualizací: webové služby lze nasazovat častěji, desktopové klienty obvykle méně často (okna nasazení, komunikace s uživateli, paketizace). Společná architektura musí tuto asymetrii zohlednit.

Praktické důsledky:

• Zpětná kompatibilita API je povinnost, nikoli volitelná.
• Feature Flags (funkční přepínače) pomáhají aktivovat nové funkce řízeně na straně serveru.
• Migrace schématu musí probíhat fázovaně: nejprve rozšířit databázi, pak začít službu používat, nakonec aktualizovat klienta.
• Jasná politika deprekace: staré endpointy nebo pole mazat teprve po definované době.

Zejména v regulovaných prostředích je důležité tato pravidla písemně stanovit jako architektonické řídicí zásady, aby se rozhodnutí nemusela v každém projektu znovu vynalézat.

Typické úskalí a jak se jim systematicky vyhnout

Z provozního hlediska jsou nejčastější problémy v smíšených Delphi/C# prostředích dobře předvídatelné. Pokud se jimi zabýváte brzy, dlouhodobé náklady výrazně klesnou.

Úskalí 1: duplicitní obchodní logika

Když Delphi-klient a C#-služba implementují stejné pravidla odlišně, vznikají „duchové chyby“: proces funguje v UI, ale selže při importu přes API. Protiopatření: centralizovat pravidla v doménové vrstvě (služba) nebo je jasně odborně přiřadit, včetně jednoznačných validačních odpovědí.

Úskalí 2: UI dočasná řešení místo čistých rozhraní

„Rychle zapsat pole do databáze“ může v jednotlivém případě vypadat nevinně, ale vytváří stínová rozhraní bez logování, autentizace a verzování. Lepší: důsledně používat definované koncové body, i když to zpočátku vyžaduje více disciplíny.

Úskalí 3: nejasné odpovědnosti v provozu

Pokud není jasné, který tým je odpovědný za kterou službu, který log a které provozní parametry, končí vyhledávání chyb jako ping-pong. Prakticky pomůže mapa služeb (která služba, jaké závislosti, které porty, jaké interní SLA) a jednotné runbooky pro běžné poruchy.

Úskalí 4: chybějící bezpečnostní konzistence

Portál se SSO, ale desktopový klient s lokálními administrátorskými účty je v mnoha auditech problém. Společný model identity a rolí snižuje riziko a nároky na support.

Pomoc při rozhodování: Co zůstane v Delphi, co půjde do C#?

Smysluplné rozdělení závisí méně na ideologii než na blízkosti k procesům a provozních požadavcích. Jako orientaci z architektonického a provozního pohledu:

• Delphi je často vhodné pro: stávající Windows-desktopové klienty (VCL), vysoce responzivní UI pracovní toky, scénáře blízké offline provozu, dlouhodobou údržbu dříve vyvinutých uživatelských rozhraní.
• C# je často vhodné pro: centrální REST-API, integrační služby do ERP/DMS/CRM, komponenty blízké identity, portály a backendové procesy s vysokou frekvencí změn.
• Rozhodnout cíleně: datová logika a validace by neměly být „v klientovi“, pokud existuje více frontendů (desktop, portál, importní úlohy).

Důležité: Cílem není „vše do C#“, ale spolehlivá celková architektura, ve které jsou kroky modernizace plánovatelné a firemní procesy běží stabilně.

Cesta modernizace: krok za krokem od aplikace k systému

V praxi je společná architektura často přechodným stavem, ale trvá dlouho. Realistická cesta modernizace se vyhýbá rozsáhlým projektům s vysokým rizikem a staví na měřitelných dílčích cílech:

1. Stabilizovat rozhraní: zavést REST API jako funkční hranici, i když interně ještě není vše „hezky“.
2. Modernizovat přístup k datům: BDE nahrazení, ovladače, 64bitová podpora, jasné transakce.
3. Centralizovat správu identity: SSO a model rolí pro všechny způsoby přístupu.
4. Zjednotit provoz: logování/monitoring/health, jasná nasazení, reprodukovatelná prostředí.
5. Oddělit odborné moduly: zejména části s vysokou změnovou intenzitou přesunout do služeb, UI postupně zjednodušit.

Toto pořadí není dogmatické, ale typicky minimalizuje závislosti: bez stabilních rozhraní a provozního konceptu bude každá další změna dražší.

Fazit: Integration ist eine Architekturaufgabe, keine Sprachenfrage

Udržitelná kombinace Delphi a C# nevznikne „mostovými knihovnami“, ale jasnými funkčními hranicemi, čistými datovými smlouvami a provozním konceptem, který bere vážně monitoring, bezpečnost a správu vydání. Pokud C# a Delphi v společné architektuře hrají vědomě podle odpovědností, firmy získají především jedno: modernizaci bez přerušení procesů. Delphi může nadále spolehlivě nést stabilní desktopové pracovní toky, zatímco C#-služby poskytují integraci, webová API a portály jako centrální platformní funkce.

Pokud chcete postupně modernizovat existující Delphi prostředí nebo čistě napojit C# služby, je architektonické review se zaměřením na rozhraní, data, provoz a bezpečnost nejrychlejší cesta k podloženým rozhodnutím. Více k tomu v přímé konzultaci:

V odborném prostředí hrají také Delphi modernizace a REST-API důležitou roli u stávajícího softwaru, když integrace, datové toky a další vývoj musí hladce spolupracovat.

Prodiskutujte projekt nebo modernizační záměr s Net-Base.