C# in Delphi v skupni arhitekturi: pragmatična integracija namesto bodisi-ali

V mnogih IT-oddelkih je izhodišče podobno: stabilna, procesno bližnja Delphi-namizna aplikacija nosi kritične procese, medtem ko nove zahteve pritiskajo v smeri spleta, portalov, mobilne uporabe in integracije s storitvami v oblaku. Hkrati je C# v mnogih podjetjih uveljavljen pri storitvah, spletnih API-jih in integraciji identitet. Ključno vprašanje zato ni več „Delphi ali C#?“, temveč: C# und Delphi in einer gemeinsamen Architektur združiti tako, da sta obratovanje, vzdrževanje, upravljanje podatkov in varnost obvladljivi.

Ta prispevek opisuje praktična arhitekturna načela, ki so se izkazala v poslovnih okoljih, kjer vsega ni mogoče ali ni smiselno graditi znova. Poudarek je na jasnih odgovornostih med namiznim odjemalcem, storitvami, podatki in vmesniki – ter na tem, kako načrtovati korake modernizacije z nizkim tveganjem, ne da bi ogrozili tekoče procese.

Zakaj so v podjetjih mešani skladi običajni

Razvite digitalne rešitve v podjetjih redko nastanejo na zelenem polju. Delphi-aplikacije so bile pogosto več let nadgrajevane, tesno ob poslovnih procesih, z obsežno podatkovno logiko in globokim znanjem o posebnih primerih. Paralelno so nastale nove zahteve: portali za samooskrbo, avtomatizirane izmenjave podatkov, povezave DMS/CRM/ERP, večstranknost, boljša revizijska sledljivost ali Single Sign-on.

C# v tem kontekstu pogosto prinaša prednosti pri spletnih in servisnih ekosistemih: širok spekter gostovanja, standardizirana vmesna programska oprema, dobra integracija s ponudniki identitet in uveljavljeni vzorci za spletne API-je. Delphi pa ostaja močna, ko gre za zmogljive Windows-namizne odjemalce, dolgoročno vzdrževane VCL-aplikacije ali specifične multiplatformne odjemalce (npr. preko FMX).

Zato mešanica ni „poseben primer“, temveč realističen odziv na varovanje naložb in pritisk za modernizacijo. Ključno je, da skupno obratovanje ne postane trajno gradbišče.

Arhitekturni princip: jasni sloji namesto jezikovnih meja

Ko se srečata dva jezika, je velika skušnjava, da ločitev organiziramo glede na tehnologijo („Vse Delphi je zastarelo, vse C# je novo“). Tehnično to pogosto deluje kratkoročno, vendar dolgoročno povzroči trenja: dvojna poslovna pravila, nejasne odgovornosti in težko reproducibilne napake.

Namesto tega se je obnesla funkcionalna slojevitost, pogosto izvedena kot Layer-3 arhitektura: predstavitev (UI), domena (poslovna logika) in infrastruktura (dostop do podatkov, zunanji sistemi). Namen ni toliko učbeniški model, temveč konkreten učinek v praksi: odločitve o podatkih, validacijah in potekih dela se sprejemajo na enem mestu in se preko stabilnih vmesnikov zagotavljajo naprej.

V mešani arhitekturi to v praksi pomeni: Delphi lahko še naprej zagotavlja UI-del (ali določene poteke dela), medtem ko C# storitve zapakirajo funkcionalno domensko plast – ali obratno. Pomembno je, da je meja med sloji tehnično čista in testna.

C# in Delphi v skupni arhitekturi: trije preverjeni vzorci integracije

Za povezavo med Delphi in C# ni »enega« pravilnega načina. Dobre odločitve temeljijo na obratovanju, varnostnih zahtevah, latenci, obsegu podatkov in ciklih izdaj. V praksi so se oblikovali trije vzorci.

1) Storitvena usmerjenost preko HTTP/REST kot standardna povezava

Najbolj robustna za obratovanje in nadaljnji razvoj je pogosto povezava preko REST-API-jev (HTTP-bazirane vmesnike). Delphi-odjemalci kličejo C#- ali Delphi-storitve; C#-portali uporabljajo iste končne točke. Ta ločitev naredi izdaje bolj načrtljive: posodobitev odjemalca ni nujna, če API ostane združljiv s prejšnjimi različicami.

Pomembna je profesionalna izvedba: časovne omejitve (Timeouts), ponovni poskusi (Retries), idempotenca (ponovljivi zahtevki brez stranskih učinkov), jasne kode napak in strategija verzioniranja. Za administracijo in obratovanje šteje tudi: enotni dnevniki (Logs), sledljive Request-IDs in dobro merljivi odzivni časi.

2) Skupna baza podatkov: le s jasnimi pravili

Skupni dostop do baze podatkov za Delphi in C# je sprva mamljiv zaradi hitrosti. Na dolgi rok pa predstavlja tveganje, če obe strani neposredno pišeta v isti nabor tabel. Razlog: poslovna pravila se preselijo v triggerje, shranjene procedure ali »nekje v odjemalcu«. To otežuje analizo napak in revizije.

Če je skupna baza neizogibna (npr. v prehodnih fazah), pomagajo jasna pravila:

• Centralizirati pisne dostope: en sistem je »System of Record« za določene entitete.
• Določiti pogodbe: pogledi (Views) ali API-ji kot stabilen sloj za branje namesto neposrednih dostopov do tabel.
• Načrtovati migracijska okna: spremembe v podatkovni bazi uvajati vedno nazaj združljivo (npr. nove stolpce najprej kot opcijske).

Tehnično je baza podatkov potem infrastrukturna komponenta, ne integracijski bus.

3) Messaging/Events za asinhrone procese

Za razvezane tokove (npr. uvozni procesi, obvestila, nadaljnja obdelava, vmesniški opravki) je smiseln asinhron model: en sistem objavi dogodke, drugi jih obdeluje. To zmanjša neposredne odvisnosti in stabilizira obremenitvene vrhe.

Za IT-vodstvo in skrbnike je tu ključno: monitoring (dolžine vrst), dead-letter-koncepti (neuspešna sporočila), obnašanje pri ponovnem zagonu/ponovnih poskusih in jasna strokovna idempotenca. Dogodki niso nadomestilo za urejeno upravljanje osnovnih podatkov, so pa koristno orodje za robustne procesne verige.

Pogodbe o podatkih in združljivost: podcenjeno jedro

Ne glede na integracijski vzorec kakovost podatkovnih pogodb odloča o stabilnosti. Podatkovna pogodba je zavezujoč opis polj, tipov, obvezno/neobvezno in semantike. V REST-API-jih je to običajno JSON; pomembno ni »JSON sam po sebi«, temveč disciplina pri upravljanju sprememb.

Preizkušena pravila, ki občutno poenostavijo obratovanje:

• Razširjati namesto lomiti: dodajati nova polja, obstoječa polja najprej še naprej zagotavljati.
• Dokumentirati semantiko polj: ne le »string«, temveč npr. ISO-datum, časovni pas, dovoljeni stati.
• Enum-vrednosti obravnavati tolerantno: odjemalci morajo prenesti neznane vrednosti (Forward-Compatibility).
• Zavedno uporabljati verzioniranje API-jev: ne vsaka izdaja zahteva novo različico; vendar morajo biti spremembe, ki prekinjajo združljivost (Breaking Changes), jasno izolirane.

Ti vidiki so še posebej pomembni, kadar Delphi-namizni odjemalci niso tako pogosto posodobljeni kot spletne storitve.

Avtentikacija in avtorizacija: skupni varnostni model

Mešane arhitekture redkeje odpovejo zaradi »tehnike«, pogosteje zaradi neusklajene varnosti. Za podjetje šteje: kdo ima pravico do česa? Kako se to preverja? Kako se to revidira? Skupni model prepreči dvojno upravljanje uporabnikov in nasprotujoče si vloge.

V praksi to vodi v centralni sloj identitete: na primer preko SAML 2.0 (federirano Single Sign-on, pogosto v enterprise-okolju) ali OpenID Connect (na osnovi OAuth2, pogosto za sodobne spletne API-je). C#-storitve je običajno mogoče neposredno priključiti na Identity Provider; Delphi-odjemalci lahko pridobijo žetone in jih pošljejo pri klicih API. Pomembno je, da tudi namizne aplikacije nimajo »posebnih pravic« preko neposrednega dostopa do baze podatkov.

Za skrbnike ključno:

• Življenjske dobe žetonov in strategija osveževanja (da odjemalci tečejo stabilno in hkrati varno)
• Avtentikacija med storitvami (Service-to-Service Auth) za interno komunikacijo (npr. mTLS ali podpisani žetoni)
• Least Privilege: vloge in pravice ne preširoko določene
• Audit-logi: varnostno relevantna dejanja sledljivo evidentirana

Obratovalni koncepti: Windows- in Linux-storitev, IIS und Prozesse im Alltag

Arhitektura je v podjetju »dobra« le, če je upravljiva: posodobitve načrtljive, napake lokalizabilne, obremenitev obvladljiva. V mešanih okoljih so najpogostejše obratovalne variante:

• Windows- in Linux-storitev: primerne za ozadna opravila, integracijske zanke, workerje; dobro vključljive v klasične Windows-modeli obratovanja strežnikov.
• Windows- und Linux-Services/Daemon: smiselno za kontejnerizirane ali na VM temelječe modele obratovanja; pogosto stabilno v dolgotrajnem delovanju, dobra avtomatizacija preko systemd.
• Microsoft IIS: uveljavljeno gostovanje za spletne aplikacije in reverse-proxy scenarije v Windows-centriranih okoljih.

Pomembno je, da Delphi- in C#-komponente izpolnjujejo podobne obratovalne standarde: konsistentni Health-Endpoints (živi signali), določeni Timeouti, omejena poraba virov ter jasen postopek deploymenta in rollbacka. To zmanjša »tehnološko specifične« posebne obravnave.

Logging, Tracing und Metriken: ein gemeinsames Observability-Niveau

Še posebej pri dveh tehnoloških skladih so skozi celotno verigo diagnostične sledi odločilne. Tipičen problem: Delphi-odjemalec prijavi »napako pri shranjevanju«, C#-storitev ima timeout, baza podatkov poroča o zaklepanjih – brez skupnega konteksta.

V praksi se izkažejo:

• Korelacijski ID-ji za zahtevo (Client → API → DB), da se dnevniki lahko povežejo.
• Strukturirano logiranje (ključ/vrednost namesto navadnih besedilnih vrstic), za kasnejše filtriranje.
• Metrike za latenco, stopnje napak, dolžine čakalnih vrst in porabo virov.
• Klasifikacija napak: poslovne napake (validacija) ločene od tehničnih napak (timeout, omrežje).

Te osnove v praksi prihranijo več časa kot katera koli razprava o »pravilnem jeziku«.

Dostop do podatkov in migracije: BDE-zamenjava, FireDAC in sodobne baze podatkov

V Delphi-stanjih ima zgodovinsko dostop do podatkov velik pomen. Kjer so še v uporabi stari poti dostopa, kot je Borland Database Engine (BDE), se pojavi dodaten pritisk: posodobitve operacijskega sistema, prehodi na 64‑bitno, razpoložljivost gonilnikov, varnostne zahteve. BDE-zamenjava tedaj ni le modernizacija, temveč zmanjšanje tveganja.

Tipičen je prestop na BDE-zamenjava z izvorno povezavo (sodobna plast dostopa do podatkov v Delphi), v kombinaciji z bazo podatkov, ki je upravljalsko prijazna (npr. PostgreSQL, SQL Server, MariaDB). Za skupno Delphi/C#-arhitekturo sta pri tem pomembna dva vidika:

• Meje transakcij: kdo začne/zaključi transakcije in kako se urejajo paralelni zapisi?
• Strategija zaklepanja in izolacije: da namizni poteki dela in storitve ne blokirajo drug drugega.

Pri migracijah se izkaže fazno načrtovanje: najprej posodobiti gonilnike in sloj dostopa, nato konsolidirati podatkovni model, nato stabilizirati integracijske vmesnike. Tako so napake izolirljive in vrnitve (rollbacks) realistične.

Release-Management: uskladitev različnih ciklov posodobitev

Ponavljajoče se področje trenj je frekvenca posodobitev: spletne storitve je mogoče pogosteje razmestiti, namizni odjemalci pogosto redkeje (okna za razmestitev, komunikacija z uporabniki, paketiranje). Skupna arhitektura mora to asimetrijo upoštevati.

Praktične posledice:

• API-odzadnja združljivost je obvezna, ne dodatek.
• Feature Flags (funkcionalni preklopniki) pomagajo nove funkcije na strežniški strani kontrolirano aktivirati.
• Migracije sheme morajo potekati v fazah: najprej razširiti bazo podatkov, nato naj storitev začne uporabljati nove strukture, nato posodobiti odjemalca.
• Jasna deprecacija: stare končne točke ali polja odstranite šele po opredeljenem obdobju.

Še posebej v reguliranih okoljih je pomembno, da ta pravila zapišete kot arhitekturna vodila, da se odločitve ne izumljajo znova za vsak projekt.

Tipične pasti in kako jih sistematično preprečiti

Z vidika obratovanja so najpogostejše težave v mešanih Delphi/C#-okoljih dobro predvidljive. Če jih naslovite zgodaj, dolgoročni stroški znatno padejo.

Past 1: podvojena poslovna logika

Če Delphi-odjemalec in C#-storitev iste poslovne pravilnosti implementirata različno, nastanejo »nevidne napake«: proces deluje v UI, a pri uvozu preko API-ja odpove. Protiukrep: centralizirati pravila v domeničnem sloju (storitev) ali jih strokovno jasno dodeliti, vključno z nedvoumimi odgovori pri validaciji.

Past 2: UI-zaobidi namesto čistih vmesnikov

»Hitro še zapisati polje v bazo« se v posameznem primeru zdi neškodljivo, vendar ustvari senci vmesnike brez logiranja, overjanja in upravljanja različic. Bolje: dosledno uporabljati definirane končne točke, tudi če to sprva zahteva več discipline.

Past 3: nejasne odgovornosti v obratovanju

Če ni jasno, katera ekipa je odgovorna za kateri servis, kateri log in katere obratovalne parametre, se iskanje napak konča v ping-pongu. Praktično pomaga zemljevid storitev (katera storitev, katere odvisnosti, kateri porti, kateri notranji SLA-ji) in enotni Runbooks za pogoste motnje.

Past 4: pomanjkanje varnostne skladnosti

Portal s SSO, a namizni odjemalec z lokalnimi administratorskimi računi predstavlja v številnih revizijah problem. Skupni model identitet in vlog zmanjša tveganje in obremenitev podpore.

Pomoč pri odločitvi: Kaj ostane v Delphi, kaj gre v C#?

Smiselna delitev je bolj odvisna od bližine procesov in obratovalnih zahtev kot od ideologije. Kot vodilo z vidika arhitekture in obratovanja:

• Delphi je pogosto primeren za: obstoječe Windows-namizne odjemalce (VCL), zelo odzivne UI-delovne tokove, scenarije blizu offline delovanja, dolgoročno vzdrževanje uveljavljenih uporabniških vmesnikov.
• C# je pogosto primeren za: centralne REST-API-je, integracijske storitve do ERP/DMS/CRM, komponente, povezane z identiteto, portale in backend-procese z visoko frekvenco sprememb.
• Odločite se zavestno: podatkovna logika in validacija ne bi smeli biti „v odjemalcu“, če obstaja več frontendov (namizje, portal, uvozni opravki).

Pomembno: Cilj ni „vse v C#“, temveč zanesljiva celostna arhitektura, v kateri so koraki modernizacije načrtljivi in poslovni procesi delujejo stabilno.

Pot modernizacije: postopno od aplikacije k sistemu

V praksi je skupna arhitektura pogosto prehod, vendar dolgotrajen. Realistična pot modernizacije se izogiba velikim projektom z visokim tveganjem in stavi na merljive vmesne cilje:

1. Stabilizirati vmesnike: REST-API kot funkcionalno mejo uvesti, tudi če interno še ni vse „lepo“.
2. Modernizirati dostop do podatkov: BDE-zamenjava, gonilniki, 64‑bitna podpora, jasne transakcije.
3. Centralizirati identiteto: SSO in model vlog za vse načine dostopa.
4. Uskladiti obratovanje: logiranje, monitoring, health, jasni postopki nameščanja, reproducibilna okolja.
5. Ločiti funkcionalne module: posebej dele z veliko spremembami premakniti v storitve, uporabniški vmesnik postopoma poenostavljati.

Ta vrstni red ni dogmatičen, vendar običajno minimizira odvisnosti: brez stabilnih vmesnikov in operativnega koncepta postane vsaka nadaljnja sprememba dražja.

Zaključek: Integracija je arhitekturna naloga, ne vprašanje jezikov

Vzdržna kombinacija Delphi in C# ne nastane z „mostovnimi knjižnicami“, temveč z jasnimi funkcionalnimi mejami, čistimi podatkovnimi pogodbami in operativnim konceptom, ki resno obravnava monitoring, varnost in Release-Management. Ko C# in Delphi v skupni arhitekturi zavestno sodelujeta po odgovornostih, podjetja pridobijo predvsem eno: modernizacijo brez prekinitve procesov. Delphi lahko še naprej zanesljivo nosi stabilne namizne delovne tokove, medtem ko C#-storitev zagotavlja integracijo, Web-API-je in portale kot osrednje platformne funkcije.

Če želite postopoma modernizirati obstoječe Delphi-okolje ali čisto povezati C#-storitev, je arhitekturni pregled s pogledom na vmesnike, podatke, obratovanje in varnost najhitrejša pot do zanesljivih odločitev. Več o tem v neposrednem pogovoru:

V strokovnem okolju imajo prav tako Delphi modernizacija in REST-API za obstoječo programsko opremo pomembno vlogo, ko morajo integracije, pretoki podatkov in nadaljnji razvoj nemoteno sodelovati.

Pogovorite se o projektu ali načrtu modernizacije z Net-Base.