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

A moltes IT-departaments la situació inicial és similar: una aplicació d’escriptori estable i pròxima als processos Delphi sustenta processos crítics, mentre que noves exigències 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, per tant, ja no és «Delphi o C#?», sinó: combinar C# i Delphi en una arquitectura comuna de manera que l’operació, el manteniment, l’emmagatzematge de dades i la seguretat siguin gestionables.

Aquesta entrada descriu principis d’arquitectura aplicables a la pràctica, que funcionen en entorns empresarials on no tot es pot o s’ha de reconstruir. El focus està en responsabilitats clares entre el client d’escriptori, els serveis, les dades i les interfícies —i en com planificar passos de modernització amb baix risc, sense posar en perill els processos en execució.

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

Les solucions digitals empresarials consolidades rarament neixen sobre terreny verge. Les aplicacions Delphi sovint s’han anat ampliant al llarg d’anys, a prop dels processos de negoci, amb una lògica de dades àmplia i un coneixement profund dels casos especials. Paral·lelament han sorgit noves exigències: portals d’autoservei, intercanvis de dades automatitzats, connexió amb DMS/CRM/ERP, capacitat multiempresa, major capacitat d’auditoria o Single Sign-on.

En aquest context, C# sovint ofereix avantatges per a ecosistemes web i de serveis: ampli espectre d’allotjament, middleware estandarditzada, bona integració amb proveïdors d’identitat i patrons consolidats per a Web-APIs. En canvi, 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 més important és que l’operació conjunta no es converteixi en una obra permanent.

Principi d’arquitectura: capes clares en comptes de fronteres de llenguatge

Quan convergeixen dues plataformes, la temptació d’organitzar la separació segons la tecnologia és gran («tot Delphi és legacy, tot C# és nou»). Tècnicament això pot funcionar a curt termini, però a la llarga genera fricció: regles de negoci duplicades, responsabilitats poc clares i errors difícils de reproduir.

En canvi, ha demostrat ser eficaç una estratificació orientada al domini, sovint implementada com una Layer-3 Arquitectura: presentació (UI), domini (lògica de negoci) i infraestructura (accés a dades, sistemes externs). La qüestió no és tant el model de llibre de text, sinó l’efecte concret en el dia a dia: les decisions sobre dades, validacions i fluxos de treball es prenen en un sol lloc i s’exposen mitjançant interfícies estables.

En una arquitectura mixta això significa pràcticament: Delphi pot continuar subministrant una part de la UI (o determinats fluxos de treball), mentre que C# serveis encapsulen una capa de domini —o a l’inrevés. El més important és que el límit entre les capes sigui tècnicament net i testable.

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

Per a l’acoblament de Delphi i C# no existeix «l’únic» camí correcte. Bones decisions s’orienten per l’explotació, els requisits de seguretat, la latència, el volum de dades i els cicles de llançament. A la pràctica s’han establert tres patrons.

1) Orientació a serveis mitjançant HTTP/REST com a acoblament estàndard

Sovint, la solució més robusta per a l’explotació i el desenvolupament continu és una integració via APIs REST (interfícies basades en HTTP). Els clients Delphi fan crides a serveis de C# o de Delphi; els portals C# utilitzen els mateixos punts finals. Aquesta desconnexió fa que els llançaments siguin més previsibles: no cal obligatòriament un update del client si l’API manté compatibilitat cap enrere.

És crucial una definició professional: timeouts, reintents, idempotència (peticions repetibles sense efectes secundaris), codis d’error clars i una estratègia de versionat. Per a l’administració i l’explotació també compten: logs unificats, IDs de petició rastrejables 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 atractiu perquè al principi és ràpid. A llarg termini, però, és arriscat si ambdós sistemes escriuen directament sobre el mateix conjunt de taules. El motiu: les regles de negoci es desplacen a triggers, procediments emmagatzemats o a „en algun lloc del client“. Això complica l’anàlisi d’errors i les auditories.

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

• Centralitzar els accessos d’escriptura: un sistema és el «System of Record» per a determinades entitats.
• Definir contractes de dades: vistes o APIs com a capa de lectura estable en lloc d’accés directe a taules.
• Planificar finestres de migració: desplegar els canvis de base de dades sempre de forma compatible cap enrere (p. ex., noves columnes primer opcionals).

Tècnicament, la base de dades passa a ser una component d’infraestructura, no el bus d’integració.

3) Messaging/Events per a processos asíncrons

Per a fluxos desacoblats (p. ex., processos d’importació, notificacions, postprocessat, 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 els pics de càrrega.

Per a direcció IT i administradors és important: monitoratge (longituds de cua), conceptes de dead-letter (missatges fallits), comportament de reexecució i una idempotència funcional clara. Els esdeveniments no són un substitut per una gestió neta de dades mestres, però són una eina útil 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 APIs REST això és típicament JSON; el rellevant no és el „JSON en si“, sinó la disciplina en el tractament dels canvis.

Regles provades que faciliten notablement l’explotació:

• Ampliar en comptes de trencar: afegir camps nous i seguir proporcionant els antics inicialment.
• Documentar la semàntica dels camps: no només „string“, sinó p. ex. data ISO, zona horària, estats permesos.
• Tractar amb tolerància els valors enum: els clients han de sobreviure valors desconeguts (compatibilitat cap endavant).
• Aplicar versionat d’API de manera conscient: no cada llançament necessita 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 la «tecnologia», amb més freqüència per una seguretat inconsistent. Per a les empreses compta: Qui pot fer què? Com es verifica? Com s’audita? Un model comú evita una gestió d’usuaris duplicada i rols contradictoris.

En la pràctica això condueix a una capa d’identitat central: per exemple mitjançant SAML 2.0 (Single Sign-On federat, habitual en entorns empresarials) o OpenID Connect (basat en OAuth2, sovint per a APIs web modernes). C#-Services es poden integrar normalment directament amb un proveïdor d’identitat; Delphi-clients poden obtenir Tokens i adjuntar-los a les crides d’API. És important que també les aplicacions d’escriptori no tinguin „privilegis especials“ mitjançant accés directe a la base de dades.

Central per als administradors:

• Temps de vida dels Tokens i estratègia de renovació (perquè els clients funcionin de manera estable i alhora siguin segurs)
• Autenticació servei-a-servei per a la comunicació interna (p. ex. mTLS o Tokens signats)
• Mínim privilegi: no definir rols ni permisos massa amplis
• Registres d’auditoria: registrar de forma rastrejable les accions rellevants per a la seguretat

Conceptes d’operació: Windows- i Linux-Services, IIS i processos en el 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-Services: adequats per a tasques en segon pla, execucions d’interfícies, workers; fàcil integració en models operatius de servidors Windows clàssics.
• Windows- i Linux-Services/Daemon: indicats per a models operatius basats en contenidors o VM; sovint estables en funcionament continu, amb bona automatització via systemd.
• Microsoft IIS: hosting consolidat per aplicacions web i escenaris de reverse-proxy en entorns centrats en Windows.

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

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

Especialment amb dos stacks tecnològics, les cadenes de diagnosi de punta a punta són determinants. Un problema típic: el client Delphi informa „Error en desar“, el servei C# té un timeout, la base de dades reporta bloquejos — sense un context comú.

A la pràctica són recomanables:

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

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

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

En inventaris Delphi l’accés a dades ha tingut històricament un paper important. Allà on encara s’utilitzen vies d’accés antigues com la Borland Database Engine (BDE), s’hi genera pressió addicional: actualitzacions del sistema operatiu, transicions a 64 bits, disponibilitat de controladors, requisits de seguretat. Un BDE-reemplaçament no és només modernització, sinó reducció de risc.

Tipicament es migra a un BDE-reemplaçament amb vinculació nativa (capa d’accés a dades moderna en Delphi), combinat amb una base de dades operativament manejable (p. ex. PostgreSQL, SQL Server, MariaDB). Per a una arquitectura conjunta Delphi/C# són importants dos aspectes:

• Límits de transacció: qui inicia/commit­a les transaccions, i com es regulen els accessos d’escriptura paral·lels?
• Estratègia de bloqueig i d’aïllament: perquè els fluxos de treball d’escriptori i els serveis no es bloquegin mútuament.

A les migracions funciona 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í es fan les fonts d’errors aïllables i els rollbacks es tornen realistes.

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

Un camp de tensions recurrent és la freqüència d’actualitzacions: els serveis web es poden desplegar amb més freqüència, mentre que els clients d’escriptori sovint menys (finestres de rollout, comunicació amb usuaris, empaquetatge). Una arquitectura comuna ha de considerar aquesta asimetria.

Conseqüències pràctiques:

• Compatibilitat cap enrere de l’API és obligatòria, no una opció.
• Feature Flags (commutadors funcionals) ajuden a activar noves funcions al costat del servidor de manera controlada.
• Migracions d’esquema han d’executar-se per fases: primer ampliar la base de dades, després el servei l’ha d’utilitzar i finalment actualitzar el client.
• Deprecació clara: eliminar punts finals o camps antics només després d’un període definit.

Particularment en entorns regulats és important fixar aquestes regles per escrit com a directrius arquitectòniques, perquè les decisions no es reinventin projecte a projecte.

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

Des de la perspectiva d’operacions, els problemes més comuns en paisatges mixtos Delphi/C# són força previsibles. Si s’aborden aviat, els costos a llarg termini disminueixen de manera apreciable.

Obstàcul 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 UI però falla a l’importació via API. Contramesura: centralitzar les regles a la capa de domini (servei) o assignar-les clarament des del punt de vista funcional, incloent respostes de validació inequívocs.

Obstàcul 2: solucions a la UI en comptes d’interfícies netes

«Fer ràpidament que es faci un escrit en un camp de la base de dades» pot semblar inofensiu en un cas concret, però genera interfícies sombra sense logging, autenticació ni versionat. Millor: passar sistemàticament per punts finals definits, encara que inicialment requereixi més disciplina.

Obstàcul 3: responsabilitats poc clares en l’operació

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

Obstacle 4: manca de coherència en matèria de seguretat

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

Ajuda per a la decisió: Què es manté a Delphi, què es trasllada a C#?

La separació raonable depèn menys d’ideologies i més de la proximitat als processos i dels requeriments d’operació. Com a orientació des de la perspectiva d’arquitectura i operacions:

• Delphi és sovint adequat per a: clients d’escriptori existents Windows (VCL), fluxos d’interfície d’usuari molt reactius, escenaris propers a l’operació offline, manteniment a llarg termini d’interfícies consolidades.
• C# és sovint adequat per a: APIs centrals REST, serveis d’integració amb ERP/DMS/CRM, components propers a Identity, portals i processos de backend amb alta freqüència de canvis.
• Decidir de manera conscient: 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 «tot cap a C#», sinó una arquitectura global sòlida en la qual els passos de modernització siguin planificables i els processos empresarials funcionin de manera estable.

Fulla de ruta de modernització: pas a pas de l’aplicació al sistema

En la pràctica, una arquitectura comuna sovint és una transició, però una de llarga durada. Una fulla de ruta de modernització realista evita grans projectes d’alt risc i aposta per objectius intermedis mesurables:

1. Estabilitzar les interfícies: introduir una API REST com a frontera funcional, encara que internament no tot sigui «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/monitorització/health, desplegaments clars, entorns reproduïbles.
5. Desacoblar mòduls funcionals: desplaçar a serveis les parts amb alta intensitat de canvis, reduir progressivament la interfície d’usuari.

Aquesta seqüència no és dogmàtica, però normalment minimitza dependències: sense interfícies estables i un concepte d’operació, qualsevol canvi addicional esdevé més car.

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

Una combinació sòlida de Delphi i C# no s’aconsegueix amb «biblioteques de pont», sinó amb vores funcionals clares, contractes de dades nets i un concepte d’operació que prengui seriosament la monitorització, la seguretat i la gestió de versions. Quan C# i Delphi en una arquitectura comuna juguen conjuntament i de manera conscient segons les responsabilitats, les empreses guanyen sobretot una cosa: modernització sense ruptures de procés. Delphi pot continuar suportant de manera fiable fluxos de treball d’escriptori estables, mentre que els serveis C# proporcionen integració, Web-APIs i portals com a funcions centrals de plataforma.

Si voleu modernitzar pas a pas una arquitectura existent Delphi o connectar netament serveis C#, una revisió d’arquitectura amb visió sobre interfícies, dades, operació i seguretat és la via més ràpida cap a decisions sòlides. Per a més detalls en un intercanvi directe:

En l’àmbit funcional també tenen un paper important la Delphi Modernització i la REST-API per a programari existent, quan les integracions, els fluxos de dades i el desenvolupament continu han de funcionar de manera coherent.

Parli del projecte o de la iniciativa de modernització amb Net-Base.