C# och Delphi i en gemensam arkitektur: pragmatisk integration istället för antingen-eller

I många IT‑avdelningar är utgångsläget likartat: en stabil, processnära Delphi-desktopapplikation bär kritiska processer, samtidigt som nya krav skjuter i riktning mot webben, portaler, mobil användning och integration med molntjänster. Samtidigt är C# etablerat i många företag när det gäller tjänster, webb‑API:er och identity‑integration. Den centrala frågan är därför inte längre „Delphi eller C#?“, utan: C# och Delphi i en gemensam arkitektur att kombinera så att drift, underhåll, datahantering och säkerhet förblir hanterbara.

Detta inlägg beskriver praktikbara arkitekturprinciper som beprövats i företagsmiljöer där inte allt kan eller bör byggas om. Fokus ligger på tydliga ansvarsområden mellan desktopklient, tjänster, data och gränssnitt – och på hur ni planerar moderniseringssteg med låg risk utan att äventyra de löpande processerna.

Varför blandade stackar är normala i företag

Växande digitala företagslösningar uppstår sällan på grönmark. Delphi-applikationer har ofta utökats över många år, nära verksamhetsprocesserna, med omfattande datalogik och djup kunskap om specialfall. Parallellt har nya krav uppstått: självbetjäningsportaler, automatiserade datautbyten, integration av DMS/CRM/ERP, stöd för flera klienter (multitenancy), ökad auditspårbarhet eller single sign‑on.

C# erbjuder i detta sammanhang ofta fördelar för webb‑ och tjänsteekosystem: stort utbud av hostingalternativ, standardiserad middleware, god integration med identitetsleverantörer och etablerade mönster för webb‑API:er. Delphi förblir däremot stark när det gäller högpresterande Windows‑desktopklienter, långsiktigt underhållna VCL‑applikationer eller specifika multiplattforms‑klienter (t.ex. via FMX).

Blandningen är därför inget undantag utan ett realistiskt svar på investeringsskydd och moderniseringstryck. Avgörande är att den gemensamma driften inte blir en ständig byggarbetsplats.

Arkitekturprincip: tydliga lager istället för språkgränser

När två språk möts finns frestelsen att organisera separationen längs tekniklinjer („Allt Delphi är Legacy, allt C# är nytt“). Tekniskt fungerar det ofta på kort sikt, men på längre sikt leder det till friktion: dubbla affärsregler, oklara ansvarsfördelningar och svårreproducerbara fel.

I stället har en domäninriktad lagerindelning visat sig effektiv, ofta implementerad som Layer-3 Architektur: presentation (UI), domän (affärslogik) och infrastruktur (dataåtkomst, externa system). Poängen är mindre läroboksmodellen än den konkreta effekten i vardagen: beslut om data, valideringar och arbetsflöden fattas på ett ställe och exponeras via stabila gränssnitt.

I en blandad arkitektur innebär det i praktiken: Delphi kan fortsatt leverera en UI‑del (eller vissa arbetsflöden), medan C# Services kan kapsla en domänlogik – eller tvärtom. Viktigt är att gränsen mellan lagren är tekniskt ren och testbar.

C# och Delphi i en gemensam arkitektur: tre beprövade integrationsmönster

För kopplingen av Delphi och C# finns det inte „det ena“ rätta sättet. Bra beslut utgår från drift, säkerhetskrav, latens, datavolym och release-cykler. I praktiken har tre mönster framträtt.

1) Serviceorientering över HTTP/REST som standardkoppling

Den mest robusta lösningen för drift och vidareutveckling är ofta en koppling via REST-API:er (HTTP-baserade gränssnitt). Delphi-klienter anropar C#- eller Delphi-tjänster; C#-portaler använder samma endpoints. Denna avkoppling gör releaser mer planbara: en klientuppdatering är inte nödvändig så länge API:et är bakåtkompatibelt.

Viktigt är en professionell utformning: timeouts, retries, idempotens (upprepningsbara requests utan sidoeffekter), tydliga felkoder och en versionsstrategi. För administration och drift räknas dessutom: enhetliga loggar, spårbara Request-IDs och väl mätbara svarstider.

2) Gemensam databas: endast med klara spelregler

En gemensam databasåtkomst från Delphi och C# kan verka lockande eftersom det är snabbt i början. På sikt är det dock riskabelt om båda världarna skriver direkt mot samma tabeller. Anledningen: affärsregler flyttas in i triggers, lagrade procedurer eller „någonstans i klienten“. Det försvårar felsökning och revisioner.

Om en gemensam databas är oundviklig (t.ex. i övergångsfasen) hjälper tydliga regler:

• Centralisera skrivåtkomst: ett system är „System of Record“ för vissa entiteter.
• Definiera kontrakt: vyer eller API:er som stabil läslagret istället för direkta tabellåtkomster.
• Planera migrationsfönster: rulla alltid ut databasändringar bakåtkompatibelt (t.ex. nya kolumner först som valfria).

Tekniskt är databasen då en infrastrukturkomponent, inte en integrationsbuss.

3) Meddelanden/Events för asynkrona processer

För lösgjorda flöden (t.ex. importkörningar, notifieringar, efterbearbetning, gränssnittsjobb) är en asynkron modell lämplig: ett system publicerar händelser, ett annat bearbetar dem. Det minskar direkta beroenden och stabiliserar belastningstoppar.

För IT-ledning och administratörer är följande viktigt: övervakning (kölängder), dead-letter-koncept (misslyckade meddelanden), återkörningsbeteende och tydlig affärslogisk idempotens. Events ersätter inte ren stamdatahantering, men är ett bra verktyg för robusta processkedjor.

Datakontrakt och kompatibilitet: den underskattade kärnan

Oavsett integrationsmönster avgör kvaliteten på datakontrakten stabiliteten. Ett datakontrakt är den bindande beskrivningen av fält, typer, obligatoriskt/valfritt och semantik. I REST-API:er är detta typiskt JSON; viktigt är inte „JSON i sig“, utan disciplinen i hanteringen av ändringar.

Vedertagna regler som tydligt förenklar driften:

• Utöka istället för att bryta: lägg till nya fält, fortsätt först att leverera de gamla.
• Dokumentera fältsemantik: inte bara „string“, utan t.ex. ISO-datum, tidszon, tillåtna tillstånd.
• Behandla enum-värden tolerant: klienter måste klara okända värden (framåtkompatibilitet).
• Använd API-versionering medvetet: inte varje release kräver en ny version; men bakåtinkompatibla förändringar måste tydligt kapslas in.

Dessa punkter är särskilt viktiga när Delphi-desktopklienter inte kan uppdateras lika ofta som webbtjänster.

Autentisering och auktorisering: en gemensam säkerhetsmodell

Blandade arkitekturer misslyckas sällan på grund av „teknik“, oftare på grund av inkonsekvent säkerhet. För företaget är det avgörande: Vem får göra vad? Hur kontrolleras det? Hur revideras det? En gemensam modell undviker dubbel användarhantering och motsägelsefulla roller.

I praktiken leder detta till ett centralt identitetslager: till exempel via SAML 2.0 (federerat Single Sign-On, ofta i företagsmiljöer) eller OpenID Connect (baserat på OAuth2, vanligt för moderna webb-API:er). C#-Services kan vanligen kopplas direkt till en Identity Provider; Delphi-Clients kan erhålla tokens och skicka dem med vid API-anrop. Viktigt är att även skrivbordsapplikationer inte får „specialrättigheter“ genom direkt databasåtkomst.

För administratörer centralt:

• Token-livstider och refresh-strategi (så att klienter är stabila och ändå säkra)
• Service-to-Service Auth för intern kommunikation (t.ex. mTLS eller signerade tokens)
• Least Privilege: roller och behörigheter får inte vara för grovt definierade
• Audit-Logs: säkerhetsrelevanta åtgärder ska kunna spåras och loggas

Betriebskonzepte: Windows- und Linux-Services, IIS und Prozesse im Alltag

En arkitektur är i företaget bara „bra“ om den är driftsbar: uppdateringar kan planeras, fel kan lokaliseras, belastning kan kontrolleras. I blandade landskap är de vanligaste driftsvarianterna:

• Windows- und Linux-Services: lämpade för bakgrundsjobb, integrationskörningar, workers; väl integrerbara i klassiska Windows-serverdriftsmodeller.
• Windows- und Linux-Services/Daemon: lämpliga för containeriserade eller VM-baserade driftmodeller; ofta stabila i kontinuerlig drift, god automatisering via systemd.
• Microsoft IIS: etablerat hosting för webbtillämpningar och reverse-proxy-scenarier i Windows-centrerade miljöer.

Viktigt är att Delphi- och C#-komponenter uppfyller liknande driftsstandarder: konsekventa Health-Endpoints (livstecken), definierade timeouts, begränsad resursförbrukning samt en tydlig deployment- och rollback-process. Det minskar „teknologispecifika“ undantagshanteringar.

Logging, Tracing und Metriken: ein gemeinsames Observability-Niveau

Särskilt med två teknologistackar är genomgående diagnoskedjor avgörande. Ett typiskt problem: Delphi-klienten rapporterar „fel vid sparande“, C#-servicen har en timeout, databasen rapporterar lås — utan gemensam kontext.

I praktiken har följande visat sig framgångsrikt:

• Korrelations-IDs per förfrågan (Client → API → DB), så att loggar kan sammanslås.
• Strukturerad loggning (nyckel/värde istället för rena textrader), för att kunna filtrera senare.
• Metriker för latens, felrate, kölängder och resursanvändning.
• Felklassificering: affärs-/valideringsfel separat från tekniska fel (timeout, nätverk).

Dessa grundläggande åtgärder sparar i praktiken mer tid än varje diskussion om „det rätta språket“.

Datenzugriff und Migration: BDE-ersättning, FireDAC och moderna databaser

I Delphi-bestånd spelar dataåtkomst historiskt en stor roll. Där gamla åtkomstvägar som Borland Database Engine (BDE) fortfarande används uppstår ytterligare tryck: operativsystemuppdateringar, 64‑bit-övergångar, drivrutinstillgänglighet, säkerhetskrav. En BDE-ersättning är då inte bara modernisering utan riskreduktion.

Typiskt är övergången till en BDE-ersättning med native-anslutning (modern åtkomstlager i Delphi), kombinerat med en databas som är driftmässigt hanterbar (t.ex. PostgreSQL, SQL Server, MariaDB). För en gemensam Delphi/C#-arkitektur är två aspekter viktiga:

• Transaktionsgränser: Vem startar/committar transaktioner, och hur regleras parallella skrivåtkomster?
• Lås- och isolationsstrategi: så att desktoparbetsflöden och tjänster inte blockerar varandra.

Vid migreringar är en etappplanering fördelaktig: först modernisera drivrutin- och åtkomstskiktet, sedan konsolidera datamodellen, därefter stabilisera integrationsgränssnitten. På så vis blir felkällor isolerbara och rollbackar realistiska.

Release-Management: att förena olika uppdateringscykler

Ett återkommande spänningsfält är uppdateringsfrekvensen: webb­tjänster kan rullas ut oftare, desktopkunder ofta mer sällan (rollout‑fönster, användarkommunikation, paketering). En gemensam arkitektur måste ta denna asymmetri i beaktande.

Praktiska konsekvenser:

• API-bakåtkompatibilitet är obligatoriskt, inte valfritt.
• Feature Flags (funktionella omkopplare) hjälper till att aktivera nya funktioner kontrollerat på serversidan.
• Schemamigrationer måste köras i faser: utöka databasen först, låta tjänsten använda det nya, och sedan uppdatera klienten.
• Tydlig depreciering: gamla endpunkter eller fält tas bort först efter en definierad tidsperiod.

Särskilt i reglerade miljöer är det viktigt att skriftligt fastställa dessa regler som arkitektoniska styrprinciper, så att beslut inte uppfinns på nytt i varje projekt.

Typiska fallgropar och hur man systematiskt undviker dem

Ur driftsynpunkt är de vanligaste problemen i blandade Delphi/C#-landskap väl förutsägbara. Om de adresseras tidigt minskar de långsiktiga kostnaderna märkbart.

Fallgrop 1: duplicerad affärslogik

Om Delphi-klient och C#-tjänst implementerar samma regler olika uppstår ”spökfel”: en process fungerar i UI:t men misslyckas vid API‑import. Motmedel: centralisera regler i domänskiktet (tjänst) eller tilldela dem klart funktionellt, inklusive entydiga valideringssvar.

Fallgrop 2: UI-lösningar i stället för rena gränssnitt

Att „snabbt skriva ett databasfält“ kan i enstaka fall verka harmlöst, men skapar skugggränssnitt utan loggning, autentisering och versionshantering. Bättre: gå konsekvent via definierade endpunkter, även om det initialt kräver mer disciplin.

Fallgrop 3: oklara ansvarsområden i drift

Om det inte är tydligt vilket team som ansvarar för vilken tjänst, vilken logg och vilka driftsparametrar, slutar felsökningen som ping-pong. I praktiken hjälper en servicekarta (vilken tjänst, vilka beroenden, vilka portar, vilka interna SLA:er) och enhetliga runbooks för vanliga störningar.

Fallgrop 4: bristande säkerhetskonsistens

En portal med SSO, men en desktopklient med lokala administratörskonton är i många revisioner ett problem. En gemensam identitets- och rollmodell minskar risk och supportinsats.

Beslutsstöd: Vad stannar i Delphi, vad flyttas till C#?

En meningsfull uppdelning beror mindre på ideologi än på processnära och driftskrav. Som vägledning ur arkitektur- och driftsperspektiv:

• Delphi är ofta lämpligt för: befintliga Windows-desktopklienter (VCL), mycket responsiva UI-arbetsflöden, offline-nära scenarier, långsiktigt underhåll av etablerade gränssnitt.
• C# är ofta lämpligt för: centrala REST-API:er, integrationsservices till ERP/DMS/CRM, identitetsnära komponenter, portaler och backendprocesser med hög förändringstakt.
• Fatta ett medvetet beslut: Datalogik och validering bör inte ligga „i klienten“ när flera frontends finns (desktop, portal, importjobb).

Viktigt: Målet är inte „allt till C#“, utan en robust helhetsarkitektur där moderniseringssteg kan planeras och företagsprocesserna löper stabilt.

Moderniseringsväg: stegvis från applikation till system

I praktiken är en gemensam arkitektur ofta en övergång, men en lång sådan. En realistisk moderniseringsväg undviker storskaliga projekt med hög risk och satsar på mätbara delmål:

1. Stabilisera gränssnitt: Inför REST-API som en funktionell avgränsning, även om inte allt internt är „snyggt“ ännu.
2. Modernisera dataåtkomst: BDE-avveckling, drivrutiner, 64‑bit-stöd, tydliga transaktioner.
3. Centralisera identitet: SSO och rollmodell för alla åtkomstvägar.
4. Enhetlig drift: Logging/Monitoring/Health, tydliga deployments, reproducerbara miljöer.
5. Avkoppla domänspecifika moduler: förflytta särskilt förändringsintensiva delar till tjänster, stegvis förenkla UI.

Denna ordning är inte dogmatisk, men den minimerar typiskt beroenden: Utan stabila gränssnitt och ett driftkoncept blir varje ytterligare förändring dyrare.

Slutsats: Integration är en arkitekturfråga, inte en språkfråga

En hållbar kombination av Delphi och C# uppstår inte genom „bryggbibliotek“, utan genom tydliga funktionella gränser, rena datakontrakt och ett driftkoncept som tar monitoring, säkerhet och release-hantering på allvar. När C# och Delphi i en gemensam arkitektur medvetet samspelar längs ansvarslinjerna, vinner företag framförallt en sak: modernisering utan processbrott. Delphi kan fortsätta tillförlitligt bära stabila desktoparbetsflöden, medan C#-tjänster tillhandahåller integration, web-API:er och portaler som centrala plattformsfunktioner.

Om ni vill modernisera en befintlig Delphi-landskap stegvis eller ansluta C#-tjänster på ett ordnat sätt, är en arkitekturgranskning med fokus på gränssnitt, data, drift och säkerhet det snabbaste sättet till välgrundade beslut. Mer om detta i direkt dialog:

I det fackliga sammanhanget spelar även Delphi modernisering och REST-API för befintlig programvara en viktig roll när integrationer, dataflöden och fortsatt utveckling måste samspela på ett ordnat sätt.

Diskutera projekt eller moderniseringsinitiativ med Net-Base.