C# i Delphi en una arquitectura conjunta: integració pragmàtica en lloc de l'opció 'o l'un o l'altre'

A moltes IT-Abteilungen la situació de partida és similar: una aplicació d’escriptori Delphi estable i pròxima als processos sosté fluxos crítics, mentre que nous requisits empenyen cap al web, portals, ús mòbil i integració amb serveis al núvol. Al mateix temps, C# està implantat en moltes empreses quan es tracta de serveis, Web-APIs i integració d’identitat. La pregunta central, doncs, ja no és «Delphi o C#?», sinó: combinar C# i Delphi en una arquitectura conjunta de manera que l’operació, el manteniment, l’emmagatzematge de dades i la seguretat es mantinguin controlables.

Aquest article descriu principis d’arquitectura aplicables en la pràctica, que han demostrat la seva eficàcia en entorns empresarials on no es pot o no es vol reconstruir-ho tot. El focus està en responsabilitats clares entre client d’escriptori, serveis, dades i interfícies — i en com planificar passos de modernització amb baix risc, sense posar en perill els processos en funcionament.

Per què les piles mixtes són habituals a les empreses

Les solucions digitals empresarials creixudes rarament neixen en un entorn net. Les aplicacions Delphi sovint s’han ampliat durant molts anys, properes als processos de negoci, amb lògica de dades extensa i un coneixement profund dels casos especials. Paral·lelament han sorgit nous requisits: portals d’autoservei, intercanvis de dades automatitzats, connexió de DMS/CRM/ERP, capacitat multiclient, major auditabilitat o Single Sign-on.

En aquest context, C# sovint ofereix avantatges per a ecosistemes web i de serveis: un ampli espectre d’allotjament, middleware estandarditzada, bona integració amb Identity Provider i patrons establerts per a Web-APIs. Delphi continua sent fort quan es tracta de clients d’escriptori Windows d’alt rendiment, aplicacions VCL mantingudes a llarg termini o clients multiplataforma específics (p. ex. via FMX).

Per això la combinació no és un «cas excepcional», sinó una resposta realista a la protecció de la inversió i a la pressió per modernitzar. El decisiu és que l’operació conjunta no es converteixi en una obra permanent.

Principi d’arquitectura: capes clares en lloc de límits per llenguatge

Quan es combinen dues tecnologies, la temptació és gran d’organitzar la separació segons la tecnologia («Tot el que és Delphi és Legacy, tot el que és C# és nou»). Tècnicament això sovint funciona a curt termini, però a la llarga provoca friccions: regles de negoci duplicades, responsabilitats poc clares i errors difícils de reproduir.

En canvi, ha demostrat ser eficaç una estratificació funcional, sovint implementada com a Layer-3 arquitectura: presentació (UI), domini (lògica de negoci) i infraestructura (accés a dades, sistemes externs). El punt no és tant el model del manual, sinó l’efecte concret en el dia a dia: les decisions sobre dades, validacions i workflows es prenen en un únic lloc i s’exposen mitjançant interfícies estables.

En una arquitectura mixta això vol dir pràcticament: Delphi pot continuar proporcionant una part d’UI (o determinats workflows), mentre que C# serveis encapsulen una capa de domini funcional — o a l’inrevés. És important que la vora entre les capes sigui tècnicament neta i testable.

C# i Delphi en una arquitectura comuna: tres patrons d’integració provats

Per a l’acoblament de Delphi i C# no existeix un únic camí correcte. Les bones decisions s’orienten pel funcionament, els requisits de seguretat, la latència, el volum de dades i els cicles de llançament. A la pràctica s’han consolidat tres patrons.

1) Orientació a serveis via HTTP/REST com a acoblament estàndard

Una connexió sobre REST-APIs (interfícies basades en HTTP) sol ser la més robusta per a l’operació i l’evolució. Els clients Delphi invoquen serveis C# o Delphi; els portals C# utilitzen els mateixos endpoints. Aquest desacoblament fa que els llançaments siguin més planificables: no cal obligatòriament actualitzar el client si l’API manté compatibilitat cap enrere.

És important una definició professional: timeouts, retries, idempotència (peticions repetibles sense efectes secundaris), codis d’error clars i una estratègia de versionat. Per a administració i explotació també compta: logs uniformes, IDs de petició traçables i temps de resposta fàcilment mesurables.

2) Base de dades compartida: només amb regles clares

Un accés compartit a la base de dades per part de Delphi i C# resulta temptador perquè al principi és ràpid. A llarg termini, però, és arriscat si ambdós entorns escriuen directament sobre el mateix conjunt de taules. La raó: les regles de negoci es traslladen a triggers, stored procedures o a ‚en algun lloc del client‘. Això dificulta l’anàlisi d’errors i les auditories.

Si una base de dades compartida és inevitable (p. ex. en fases de transició), ajuden unes regles clares:

• Centralitzar els escrits: un sistema és el „System of Record“ per a certes entitats.
• Definir contractes: views o APIs com a capa de lectura estable en lloc d’accés directe a taules.
• Planificar finestres de migració: desplegar canvis a la base de dades sempre de manera retrocompatible (p. ex. afegir primer columnes opcionals).

Tècnicament la base de dades és una component d’infraestructura, no el bus d’integració.

3) Messaging/Events per a processos asíncrons

Per a fluxos desacoblats (p. ex. imports, notificacions, postprocessament, tasques d’interfície) té sentit un model asíncron: un sistema publica esdeveniments i un altre els processa. Això redueix dependències directes i estabilitza pics de càrrega.

Per a direcció d’IT i administradors és important aquí: monitoratge (longituds de cues), conceptes de dead-letter (missatges fallits), comportament de reinici i idempotència funcional clara. Els events no substitueixen una gestió neta de dades mestres, però són una eina adequada per a cadenes de procés robustes.

Contractes de dades i compatibilitat: el nucli subestimat

Independentment del patró d’integració, la qualitat dels contractes de dades determina l’estabilitat. Un contracte de dades és la descripció vinculant de camps, tipus, obligatori/opcional i semàntica. En les REST-APIs això sol ser JSON; el que importa no és „JSON en si mateix“, sinó la disciplina en el tractament dels canvis.

Regles provades que simplifiquen notablement l’explotació:

• Ampliar en lloc de trencar: afegir camps nous, continuar proporcionant els antics inicialment.
• Documentar la semàntica dels camps: no només „string“, sinó per exemple data ISO, zona horària, estats admesos.
• Tractar els valors enum amb tolerància: els clients han de sobreviure a valors desconeguts (compatibilitat cap endavant).
• Aplicar versionat d’API de manera conscient: no tots els llançaments requereixen una nova versió; però els canvis incompatibles han d’estar clarament encapsulats.

Aquests punts són especialment importants quan els clients d’escriptori Delphi no es poden actualitzar tan sovint com els serveis web.

Autenticació i autorització: un model de seguretat comú

Les arquitectures mixtes rarament fallen per «tecnologia», sovint fracassen per una seguretat inconsistent. Per a l’empresa importa: qui pot fer què? Com es comprova això? Com s’audita? Un model comú evita duplicar la gestió d’usuaris i rols contradictoris.

En la pràctica això condueix a una capa d’identitat central: per exemple a través de SAML 2.0 (single sign-on federat, freqüent en entorns enterprise) o OpenID Connect (basat en OAuth2, sovint per a API web modernes). C#-serveis es poden connectar normalment directament a un proveïdor d’identitat; Delphi-clients poden obtenir tokens i enviar-los amb les crides a les API. És important que també les aplicacions d’escriptori no tinguin «privilegis especials» d’accés a la base de dades.

Important per als administradors:

• Durada de vida dels tokens i estratègia de renovació (perquè els clients funcionin de manera estable i, alhora, segura)
• Autenticació servei-a-servei per a comunicació interna (p. ex. mTLS o tokens signats)
• Principi del mínim privilegi: no definir rols i permisos massa genèrics
• Registres d’auditoria: registrar de manera traçable les accions rellevants per la seguretat

Conceptes d’operació: Windows- i Linux-serveis, IIS i processos del dia a dia

Una arquitectura només és «bona» a l’empresa si és operable: actualitzacions planificables, errors localitzables, càrrega controlable. En entorns mixtes, les variants operatives més habituals són:

• Windows- i Linux-serveis: adequats per treballs en segon pla, execucions d’interfícies i workers; ben integrables en models d’operació clàssics de servidors Windows.
• Windows- i Linux-serveis/daemon: adients per models d’operació en contenidors o basats en VM; sovint estables en funcionament continu, amb bona automatització via systemd.
• Microsoft IIS: allotjament consolidat per aplicacions web i escenaris de proxy invers en entorns centrats en Windows.

És important que els components Delphi i C# compleixin estàndards operatius similars: endpoints de salut coherents (senyals de vida), timeouts definits, consum de recursos limitat, així com un procediment clar de desplegament i reversió. Això redueix tractaments especials «específics de tecnologia».

Registres, tracing i mètriques: un nivell d’observabilitat comú

Precisament amb dos stacks tecnològics, les cadenes de diagnosi transversals són determinants. Un problema típic: el client Delphi notifica «error en desar», el servei C# té un timeout, i la base de dades informa de bloquejos — sense una relació comuna.

Són pràcticament recomanables:

• IDs de correlació per cada request (Client → API → DB), per tal que els registres es puguin agregar.
• Registre estructurat (clau/valor en lloc de línies de text), per poder filtrar posteriorment.
• Mètriques per latència, taxes d’errors, longituds de cues i ús de recursos.
• Classificació d’errors: errors de negoci (validació) separats d’errors tècnics (timeout, xarxa).

Aquests fonaments estalvien en la pràctica més temps que qualsevol discussió sobre «l’idioma correcte».

Accés a dades i migració: BDE-substitució, FireDAC i bases de dades modernes

Als desplegaments de Delphi l’accés a les dades ha tingut històricament un paper important. Allà on encara s’utilitzen vies d’accés antigues com la Borland Database Engine (BDE), apareix una pressió addicional: actualitzacions del sistema operatiu, migracions a 64‑bits, disponibilitat de controladors, requisits de seguretat. Una BDE-substitució no és només una modernització, sinó una reducció del risc.

És típic la migració cap a una BDE-substitució amb connexió nativa (capa d’accés a dades moderna a Delphi), combinada amb una base de dades que sigui fàcil de gestionar en explotació (p. ex. PostgreSQL, SQL Server, MariaDB). Per a una arquitectura conjunta Delphi/C# són importants dos aspectes:

• Llindars de transacció: Qui inicia/finalitza (commit) les transaccions, i com es regulen els accessos d’escriptura paral·lels?
• Estrategia de bloqueig i d’aïllament: perquè els fluxos de treball d’escriptori i els serveis no es bloquegin mútuament.

En migracions convé una planificació per fases: primer modernitzar la capa de controladors i d’accés, després consolidar el model de dades i, finalment, estabilitzar les interfícies d’integració. Així les fonts d’errors es tornen aïllables i les reversiones realistes.

Gestió de versions: conciliar cicles d’actualització diferents

Un àmbit de tensió recurrent és la freqüència d’actualització: els serveis web es poden desplegar amb més freqüència, mentre que els clients d’escriptori sovint menys (finestres de desplegament, comunicació amb usuaris, empaquetat). Una arquitectura comuna ha d’incorporar aquesta asimetria.

Conseqüències pràctiques:

• Compatibilitat regressiva de l’API és obligatòria, no opcional.
• Feature Flags (commutadors funcionals) ajuden a activar noves funcions de manera controlada a nivell de servidor.
• Les migracions d’esquema han d’executar-se per fases: primer ampliar la base de dades, després fer servir el servei i finalment actualitzar el client.
• Deprecació clara: eliminar endpoints o camps antics només després d’un període de temps definit.

Especialment en entorns regulats, és important fixar aquestes regles per escrit com a línies mestres d’arquitectura, perquè les decisions no s’hagin de reinventar per cada projecte.

Obstacles típics i com evitar-los de manera sistemàtica

Des del punt de vista de l’operació, els problemes més freqüents en paisatges mixtos Delphi/C# són ben previsibles. Si s’aborden aviat, els costos a llarg termini disminueixen de manera apreciable.

Punt d’atenció 1: lògica de negoci duplicada

Si el client Delphi i el servei C# implementen les mateixes regles de manera diferent, apareixen «errors fantasma»: un procés funciona a la interfície d’usuari, però falla en la importació via API. Mesures: centralitzar les regles a la capa de domini (servei) o assignar-les clarament des d’un punt de vista funcional, incloent respostes de validació inequívocament interpretables.

Punt d’atenció 2: workarounds a la UI en lloc d’interfícies netes

«Afegir ràpidament un camp a la base de dades» sembla inofensiu en un cas aïllat, però genera interfícies en l’ombra sense logging, autenticació i versionat. Millor: passar sempre per endpoints definits, encara que inicialment requereixi més disciplina.

Punt d’atenció 3: responsabilitats poc clares en l’operació

Si no queda clar quin equip és responsable de quin servei, quin log i quins paràmetres d’operació, la recerca d’errors acaba convertint-se en un ping-pong. A la pràctica ajuda un mapa de serveis (quin servei, quines dependències, quins ports, quins SLA interns) i runbooks unificats per a incidències freqüents.

Problema 4: manca de coherència en la seguretat

Un portal amb SSO, però un client d’escriptori amb comptes d’administrador locals és un problema en moltes auditories. Un model d’identitat i de rols comú redueix el risc i la càrrega de suport.

Ajuda a la decisió: Què roman a Delphi i què passa a C#?

La distribució raonable depèn menys de la ideologia i més de la proximitat als processos i dels requisits d’explotació. Com a orientació des del punt de vista de l’arquitectura i l’operació:

• Delphi sovint és adequat per a: clients d’escriptori Windows existents (VCL), fluxos d’interfície d’usuari amb molt alta reactivitat, escenaris propers a l’ús offline, manteniment a llarg termini d’interfícies evolucionades.
• C# sovint és adequat per a: APIs centrals REST, serveis d’integració amb ERP/DMS/CRM, components relacionats amb la identitat, portals i processos backend amb alta freqüència de canvi.
• Decidir amb consciència: la lògica de dades i la validació no haurien d’estar „al client“ quan existeixen diversos frontends (escriptori, portal, tasques d’importació).

Important: L’objectiu no és „traslladar-ho tot a C#“, sinó una arquitectura global sòlida en què els passos de modernització siguin planificables i els processos empresarials funcionin amb estabilitat.

Camí de modernització: pas a pas de l’aplicació cap al sistema

A la pràctica, una arquitectura comuna sovint és una etapa de transició, però una de llarga durada. Un camí de modernització realista evita grans projectes d’alt risc i aposta per fites intermèdies mesurables:

1. Estabilitzar les interfícies: introduir l’API REST com a límit funcional, encara que internament no tot sigui encara „bonic“.
2. Modernitzar l’accés a dades: BDE-substitució, controladors, compatibilitat 64 bits, transaccions clares.
3. Centralitzar la identitat: SSO i model de rols per a totes les vies d’accés.
4. Unificar l’operació: logging/monitoring/health, desplegaments clars, entorns reproductibles.
5. Desacoblar mòduls funcionals: traslladar a serveis les parts amb alta intensitat de canvi, simplificar progressivament la UI.

Aquest ordre no és dogmàtic, però típicament minimitza les dependències: sense interfícies estables i un concepte d’operació, qualsevol canvi addicional serà més car.

Conclusió: la integració és una tasca d’arquitectura, no una qüestió d’idioma

Una combinació sòlida entre Delphi i C# no s’aconsegueix amb „biblioteques pont“, sinó amb límits funcionals clars, contractes de dades nets i un concepte d’operació que prengui seriosament el monitoring, la seguretat i la gestió de release. Si C# i Delphi en una arquitectura comuna juguen conjuntament i de manera conscient segons responsabilitats, les empreses guanyen sobretot una cosa: modernització sense ruptura de processos. Delphi pot continuar suportant de manera fiable fluxos de treball d’escriptori estables, mentre que C#-services proporcionen la integració, les Web-APIs i els portals com a funcions centrals de la plataforma.

Si voleu modernitzar de manera gradual un entorn Delphi existent o connectar correctament serveis C#, una revisió d’arquitectura amb atenció a interfícies, dades, operació i seguretat és el camí més ràpid cap a decisions sòlides. Més informació en un intercanvi directe:

En l’entorn funcional també tenen un paper important la Delphi modernització i l’API REST per a programari existent, quan integracions, fluxos de dades i la continuïtat del desenvolupament han de funcionar conjuntament de manera ordenada.

Parlar del projecte o del pla de modernització amb Net-Base.