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ě orientovaná Delphi desktopová aplikace zajišťuje kritické procesy, zatímco nové požadavky směřují k webu, portálům, mobilnímu využití a integraci s cloudovými službami. Současně je C# v mnoha podnicích zaveden, pokud jde o služby, webová API a integraci identity. Klíčová otázka tedy už není „Delphi nebo C#?“, ale: C# a Delphi v rámci společné architektury tak zkombinovat, aby provoz, údržba, správa dat a bezpečnost zůstaly kontrolovatelné.

Tento článek popisuje praxí ověřené principy architektury, které se osvědčily v podnikovém prostředí, kde nelze nebo není žádoucí vše znovu postavit. Důraz je kladen na jasné odpovědnosti mezi desktopovým klientem, službami, daty a rozhraními – a na to, jak plánovat kroky modernizace s nízkým rizikem, aniž by byly ohroženy běžící procesy.

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

Rozvoj digitálních podnikových řešení se zřídka děje „na zelené louce“. Aplikace Delphi byly často rozšiřovány po mnoho let, těsně vázané na provozní procesy, s rozsáhlou datovou logikou a hlubokým know‑how o výjimečných případech. Paralelně vznikly nové požadavky: samoobslužné portály, automatizovaná výměna dat, napojení DMS/CRM/ERP, podpora více klientů (multitenancy), lepší auditovatelnost nebo Single Sign-on.

C# v tomto kontextu často přináší výhody pro webová a servisní ekosystémy: široké možnosti hostingu, standardizovanou middleware, dobrou integraci s identity providery a zavedené vzory pro webová API. Delphi zůstává silná tam, kde jde o výkonné Windows desktopové klienty, dlouhodobě udržované VCL aplikace nebo specifické multiplatformní klienty (např. přes FMX).

Směs tedy není „výjimkou“, ale realistickou odpovědí na ochranu investic a tlak na modernizaci. Rozhodující je, aby společný provoz nepřerostl v trvalé rozpracované řešení.

Zásada architektury: jasné vrstvy místo technologických hranic

Když se setkají dvě technologie, pokušení je velké rozdělit zodpovědnosti podle jazyka („Všechno Delphi je legacy, všechno C# je nové“). Technicky to může krátkodobě fungovat, ale dlouhodobě to vede k třenicím: duplicitní obchodní pravidla, nejasné kompetence a obtížně reprodukovatelné chyby.

Osvedčilo se místo toho logické vrstvení, často realizované jako Layer-3 architektura: prezentace (UI), doména (obchodní logika) a infrastruktura (přístup k datům, externí systémy). Podstatné není slepě kopírovat učebnicový model, ale jeho konkrétní dopad v praxi: rozhodnutí o datech, validacích a pracovních postupech se přijímají na jednom místě a jsou vystavena přes stabilní rozhraní.

V rámci smíšené architektury to prakticky znamená: Delphi může nadále dodávat UI část (nebo určité workflowy), zatímco C# Services mohou zapouzdřit doménovou vrstvu – nebo naopak. Důležité je, aby přechod mezi vrstvami byl technicky čistý a testovatelný.

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

Pro provázání Delphi a C# neexistuje „jeden“ správný přístup. Dobrá rozhodnutí se řídí provozem, bezpečnostními požadavky, latencí, objemem dat a cykly vydávání. V praxi se ukázaly tři vzory.

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

Nejrobustnějším řešením pro provoz a další vývoj 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ávání předvídatelnějším: aktualizace klienta není nezbytná, pokud API zůstane zpětně kompatibilní.

Důležitá je profesionální implementace: Timeouts, Retries, Idempotenz (opakovatelná requesty bez vedlejších účinků), jasné chybové kódy a strategie verzování. Pro administraci a provoz pak platí: jednotné logy, sledovatelné Request‑IDs a dobře měřitelné doby odezvy.

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

Společný přístup do databáze ze strany Delphi a C# působí lákavě, protože je zpočátku rychlý. Z dlouhodobého hlediska je však rizikový, pokud obě části přímo zapisují do stejné množiny tabulek. Důvod: obchodní pravidla se přesunují do triggerů, Stored Procedures nebo „někam do klienta“. 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 je „System of Record“ pro konkrétní entity.
• Definovat smlouvy: Views nebo APIs jako stabilní vrstva pro čtení místo přímých přístupů k tabulkám.
• Plánovat migrační okna: nasazovat změny databáze vždy zpětně kompatibilně (např. nové sloupce nejdříve jako volitelné).

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

3) Messaging/Events pro asynchronní procesy

Pro oddělené toky (např. importní běhy, notifikace, následné zpracování, úlohy rozhraní) 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), dead‑letter koncepty (neúspěšné zprávy), chování při opětovném spuštění a jasná doménová idempotence. Události nejsou náhradou za kvalitní správu hlavních dat, ale jsou dobrým nástrojem pro robustní procesní řetězce.

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

Bez ohledu na integrační vzor 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 zpracování změn.

Ověřená pravidla, která provoz výrazně zjednodušují:

• Rozšiřovat místo lámat: přidávejte nová pole, stará pole nejdříve nadále vracet.
• Dokumentovat sémantiku polí: nejen „string“, ale např. ISO datum, časové pásmo, přípustné stavy.
• Enum hodnoty tolerovat: klienti musí zvládnout neznámé hodnoty (forward‑compatibility).
• Řízení verzí API používat uvážlivě: ne každé vydání potřebuje novou verzi; nekompatibilní změny musí být jasně odděleny.

Tyto body jsou obzvlášť důležité, pokud Delphi-desktopoví klienti nemohou být aktualizováni 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 smí co? Jak se to ověřuje? Jak se to auditovat? Společný model eliminuje duplicitní správu uživatelů a protichůdné role.

V praxi to vede k centrální identitní vrstvě: například přes SAML 2.0 (federované Single Sign-on, běžné v enterprise prostředí) nebo OpenID Connect (na OAuth2 založené, často pro moderní webová API). C#-servisy lze obvykle přímo připojit k Identity Provideru; Delphi-klienti mohou získat tokeny a posílat je při volání API. Důležité je, aby ani desktopové aplikace neměly „zvláštní práva“ přes přímý přístup do databáze.

Centrálně pro administrátory:

• Doba platnosti tokenů a strategie obnovy (aby klienti běželi stabilně a přitom bezpečně)
• Service-to-Service Auth pro interní komunikaci (např. mTLS nebo podepsané tokeny)
• Least Privilege: role a oprávnění neudělovat příliš hrubě
• Audit-Logs: bezpečnostně relevantní akce auditovatelně protokolovat

Provozní koncepty: Windows- und Linux-Services, IIS und Prozesse im Alltag

Architektura je v podniku „dobrá“ pouze tehdy, je-li provozovatelná: aktualizace plánovatelné, chyby lokalizovatelné, zátěž ovladatelná. Ve smíšených prostředích jsou nejčastější provozní varianty:

• Windows- und Linux-Services: vhodné pro background joby, integrační běhy, workery; dobře se integrují do klasických provozních modelů serverů Windows.
• Windows- und Linux-Services/Daemon: smysluplné pro kontejnerizované nebo VM-podnikové modely; často stabilní v dlouhodobém provozu, dobrá automatizace přes systemd.
• Microsoft IIS: zavedené hostování webových aplikací a Reverse-Proxy scénářů v Windows-centrických prostředích.

Důležité je, aby Delphi- a C#-komponenty splňovaly podobné provozní standardy: konzistentní health-endpointy (indikátory dostupnosti), definované time-outy, omezená spotřeba zdrojů a jasný postup nasazení a rollbacku. To snižuje „technologicky specifické“ výjimky v zacházení.

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#-servis má timeout, databáze hlásí zámky – bez společného kontextu.

Osvedčené praktiky jsou:

• Korrelations-IDs na request (Client → API → DB), aby bylo možné logy spojit dohromady.
• Strukturované logování (klíč/hodnota místo prostých textových řádků), kvůli pozdější filtraci.
• Metriky pro latenci, chybovost, délky front a využití zdrojů.
• Klasifikace chyb: Business-chyby (validace) odděleně od technických chyb (timeout, síť).

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

Dostup k datům a migrace: BDE-nahrazení, FireDAC a moderní databáze

V Delphi-instalacích historicky hraje přístup k datům velkou roli. Kde jsou stále v provozu staré přístupy jako Borland Database Engine (BDE), vzniká dodatečný tlak: aktualizace operačního systému, přechody na 64bit, dostupnost ovladačů, bezpečnostní požadavky. BDE-nahrazení pak není jen modernizace, ale redukce rizika.

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

• Hranice transakcí: Kdo zahajuje/potvrzuje transakce a jak se řídí paralelní zápisy?
• Strategie zámků a izolace: aby se desktopové pracovní postupy a služby navzájem neblokovaly.

Při migracích se osvědčuje plánování po fázích: nejprve modernizovat vrstvu ovladačů a přístupu, poté konsolidovat datový model a následně stabilizovat integrační rozhraní. Tím jsou zdroje chyb izolovatelné a rollbacky reálné.

Správa vydání: sladit různé cykly aktualizací

Opakující se napětí vytváří frekvence aktualizací: webové služby lze nasazovat častěji, desktopové klienty často méně často (okna nasazení, komunikace s uživateli, balení). 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í kontrolovaně aktivovat nové funkce na straně serveru.
• Migrace schématu musí probíhat fázovaně: databázi nejprve rozšířit, pak službu využít a nakonec klienta aktualizovat.
• Jasná deprekace: staré koncové body nebo pole odstraňovat až po definované době.

Obzvlášť v regulovaných prostředích je důležité tato pravidla písemně stanovit jako architektonická vodítka, aby se rozhodnutí nemusela znovu objevovat na úrovni jednotlivých projektů.

Typické úskalí a jak jim systematicky předcházet

Z pohledu provozu jsou nejčastější problémy v smíšených Delphi/C#-prostředích dobře předvídatelné. Když se řeší včas, dlouhodobé náklady výrazně klesají.

Ú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: obcházení v UI místo čistých rozhraní

„Rychle zapsat pole do databáze“ může na první pohled působit neškodně, ale vytváří stínová rozhraní bez logování, autentizace a verzování. Lepší přístup: 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čí hledá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 časté 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 podporu.

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 vodítko z pohledu architektury a provozu:

• Delphi je často vhodný pro: stávající Windows‑desktopové klienty (VCL), vysoce responzivní UI workflowy, scénáře blízké offline provozu, dlouhodobou údržbu etablovaných uživatelských rozhraní.
• C# je často vhodný pro: centrální REST‑API, integrační služby vůči ERP/DMS/CRM, komponenty blízké identitě, portály a backendové procesy s vysokou frekvencí změn.
• Rozhodujte vědomě: 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, v níž 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á, ale dlouhá. Realistická cesta modernizace se vyhýbá velkým projektům s vysokým rizikem a staví na měřitelných mezních cílech:

1. Stabilizovat rozhraní: zavést REST‑API jako jasně vymezené doménové rozhraní, i když interně ještě není všechno „krásné“.
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. Unifikovat provoz: Logging/Monitoring/Health, jasná nasazení, reprodukovatelná prostředí.
5. Oddělit funkční moduly: zejména části s vysokou mírou změn přesunout do služeb, UI postupně zjednodušit.

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

Závěr: Integrace je úkol architektury, ne otázka jazyků

Praktická kombinace Delphi a C# nevzniká prostřednictvím „mostových knihoven“, ale prostřednictvím jasných doménových hranic, čistých datových smluv a provozního konceptu, který bere monitoring, bezpečnost a řízení vydání vážně. Když C# a Delphi v rámci společné architektury úmyslně spolupracují podle odpovědností, získají firmy především jedno: modernizaci bez narušení procesů. Delphi může i nadále spolehlivě podporovat stabilní desktopové pracovní toky, zatímco C#‑služby poskytují integraci, webová API a portály jako centrální funkce platformy.

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

V odborném prostředí hrají také Delphi modernizace a REST-API pro stávající software důležitou roli, pokud integrace, datové toky a další rozvoj musí bezchybně spolupracovat.

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