Qui vol netejar arquitectures Client-Server en Delphi rarament es troba davant d’un sistema „dolent“. Sovint es tracta de programari empresarial robust que s’ha anat ampliant durant anys, que modela molts casos especials i que funciona de manera fiable en el dia a dia. El problema no ve de Delphi com a plataforma, sinó de responsabilitats desenvolupades: el client conté sobtadament lògica de dades, el „servidor“ és de fet només una base de dades, i les interfícies s’han anat afegint ad hoc. Això es paga quan apareixen nous requisits de seguretat, canvis de base de dades, VPN per a teletreball, configuracions de terminal server o integracions amb ERP, DMS o portals.
Aquest article mostra com netejar estructuradament en la pràctica paisatges client‑servidor de Delphi: sense una reconstrucció total dogmàtica, però amb objectius clars per a l’explotació, l’administració, la consistència de dades, la capacitat d’interfície i la mantenibilitat. El focus està en decisions que la direcció de TI i els responsables tècnics de projecte poden dirigir: límits d’arquitectura, estratègies de desplegament, registre (Logging), conceptes de permisos, trajectòries de migració i fonts típiques de risc.
Com es pot reconèixer que l’arquitectura Client-Server està „fusionada“
Els deutes tècnics es manifesten en l’explotació sovint abans que en el codi font. Els senyals típics no són tant „codi dolent“ sinó punts de fricció recurrents entre client, base de dades i infraestructura:
- Responsabilitats poc clares: el client „sap“ massa sobre taules, triggers, procediments emmagatzemats o fins i tot rutes de fitxers en comparticions.
- Llançaments complicats: cada petit canvi requereix el desplegament del client a moltes estacions de treball, sovint amb passos manuals.
- Accessos a dades fràgils: deadlocks aleatoris, transaccions inconsistents o bloquejos „penjats“ en pics de càrrega.
- La seguretat com a pensament posterior: els accessos a la base de dades s’executen amb permisos massa amplis; les contrasenyes estan en fitxers INI; la segmentació de xarxa trenca funcionalitats.
- Integrar costa desproporcionadament: un portal de clients o una REST-API és difícil d’implantar posteriorment perquè les regles de negoci estan distribuïdes.
- Recerca d’errors complicada: sense un registre fiable (Logging) no queda clar si els errors es generen en el client, a la xarxa, a la base de dades o en una interfície.
Si s’apliquen diversos d’aquests punts, la „neteja“ no és cosmètica, sinó una mesura per a la seguretat operativa. L’objectiu no és la perfecció, sinó un sistema que continuï essent modificable de forma fiable.
Client-Server en Delphi: Què compta realment en l’explotació
En moltes paisatges Delphi el terme „Client-Server“ s’entén implícitament com „el client parla directament amb la base de dades“. Això pot funcionar mentre no canviïn les condicions de l’entorn. Per a les empreses, però, compten altres propietats:
- Escalabilitat en el dia a dia: no benchmarks d’aparença, sinó rendiment estable en pics de càrrega típics (tancament de mes, canvi de torn, execucions d’importació).
- Facilitat de modificació: adaptacions sense reacció en cadena de desplegament, migració de dades i formació.
- Funcionament segur: permisos traçables, auditabilitat, gestió neta dels secrets (Credentials), límits de xarxa.
- Capacitat d’integració: interfícies definides en lloc d’un „segon client“ que també accedeixi directament a les taules.
Aquests objectius es poden aconseguir sense Delphi „substituir“. Decisiu és com definiu límits: què és la UI, què és la lògica de negoci, què és l’accés a dades, i a través de quines interfícies poden connectar-s’hi altres sistemes?
Posar ordre en les arquitectures client-servidor en Delphi: imatge objectiu en lloc del Big Bang
Una imatge objectiu viable a la pràctica rarament és un tall radical. Ha demostrat la seva eficàcia un enfocament incremental dins d’un marc arquitectònic clar. Sovint s’implementa com a Layer-3-Arquitectura: tres capes amb responsabilitats definides. „Layer“ significa aquí: una separació definida entre UI (presentació), lògica de negoci (regles/casos d’ús) i accés a dades (SQL, transaccions, persistència). Això es pot estructurar també dins d’un monolit Delphi abans d’extraure un servei real.
Pas 1: Fer visibles els límits d’arquitectura
Abans de reestructurar, cal saber on s’origina l’acoblament. Les violacions típiques de límits en clients Delphi són:
- Esdeveniments UI (clic de botó) contenen SQL o accés directe a taules.
- Les regles de negoci estan repartides: en part al client, en part en triggers, en part en informes o scripts d’importació.
- Les connexions a la base de dades s’obren a tot arreu „de forma ad hoc“, amb paràmetres diferents.
L’objectiu és un nucli manejable: pocs punts d’entrada a les funcions de negoci i un accés a dades central que gestioni de manera consistent connexions, transaccions i tractament d’errors.
Pas 2: „Contractes“ definir – també sense serveis
Molts equips creuen que les interfícies només apareixen amb REST. En realitat, primer necessiteu contractes interns: quines funcions existeixen, quins paràmetres es passen, quins codis d’error són admesos, quines transaccions van juntes? Aquests contractes poden existir inicialment com a mòduls/baustücke clarament definits dins del projecte Delphi. Més endavant es poden traslladar relativament netament a un REST-Server o a uns serveis Windows i Windows- i Linux-Services.
Estabilitzar l’accés a dades: FireDAC, transaccions i una estratègia clara de connexions
L’accés a dades és sovint el principal palanca per a la estabilitat en conjunts client-servidor. Dos temes dominen: connexions coherents i límits de transacció nets. En entorns Delphi la BDE-substitució amb connexió nativa (biblioteca d’accés a dades amb controladors i pool de connexions) sovint és l’eix de la modernització, especialment si encara s’utilitza BDE (Borland Database Engine, una capa d’accés a dades antiga).
BDE-substitució: Més que un canvi de controladors
Una BDE-substitució s’estima poc si es veu com a „canviar els components“. A la pràctica toca:
- Dialecte SQL i parametrització: Diferents bases de dades i controladors reaccionen de manera diferent a formats de data, tractament de NULL, ordenació i jocs de caràcters.
- Comportament de transaccions: autocommit, nivells d’aïllament (normes sobre com s’han de tractar bloquejos/lectures) i recuperació d’errors.
- Rendiment i bloquejos: Algunes lògiques antigues depenen de manera no intencionada de mecanismes implícits de bloqueig.
A nivell operatiu és important un concepte de proves que no només „fa clic“ pels formularis, sinó que simuli sota càrrega els fluxos típics de comptabilització i d’importació.
Transaktionen: Weniger Magie, mehr Regeln
In vielen gewachsenen Delphi-Clients entstehen Transaktionen zufällig: Ein Formular speichert mehrere Tabellen, aber Fehlerfälle werden nicht sauber zurückgerollt. Das führt zu Teilständen, die später „manuell bereinigt“ werden müssen. Besser ist ein konsistentes Muster:
- Transaktion pro fachlichem Vorgang (z. B. „crear comanda“, „registrar entrada de mercaderies“), nicht pro SQL-Statement.
- Klare Fehlerpfade: Bei Validierungsfehlern kein halbfertiger Datenstand, sondern kontrollierter Abbruch.
- Idempotenz bei Imports: Wiederholbares Einspielen, ohne doppelte Buchungen.
Für IT-Betrieb und Support zählt dabei vor allem: Wenn ein Vorgang scheitert, muss er nachvollziehbar scheitern – mit Logeinträgen, korrelierbaren IDs und einer eindeutigen Fehlermeldungsklasse (z. B. Berechtigung, Datenkonflikt, technischer Fehler).
Business-Logik aus dem Client herausziehen – ohne die Bedienung zu zerstören
Viele Delphi-Clients sind historisch „UI-zentriert“ gewachsen: Der Ablauf steckt in Formularen, Validierungen in OnChange-Events, Seiteneffekte in OnExit. Das ist aus Anwendersicht oft schnell und direkt – aus Architekturperspektive aber schwer zu testen und zu erweitern.
Use-Cases statt Formularlogik
Ein praxistauglicher Zwischenschritt ist die Bündelung in fachliche Use-Cases: Ein Use-Case kapselt einen Vorgang (z. B. «autoritzar factura») inklusive Validierungen, Berechnungen, Datenzugriff und Protokollierung. Die UI ruft ihn auf und zeigt Ergebnisse an, statt selbst die Regeln zu implementieren. Vorteil: Später kann derselbe Use-Case über eine REST-API genutzt werden, etwa für ein Portal oder einen Importdienst.
Regeln zentralisieren: Validierung, Nummernkreise, Zustandsmodelle
Typische Kandidaten für eine Zentralisierung sind:
- Validierungsregeln (Pflichtfelder, Wertebereiche, Plausibilitäten)
- Nummernkreise (Belege, Chargen, Vorgänge) mit Konfliktvermeidung
- Zustandsmodelle (Entwurf → geprüft → freigegeben → gebucht) mit erlaubten Übergängen
- Berechtigungsprüfungen nahe an der Business-Operation, nicht nur in der UI
Gerade bei Berechtigungen ist das entscheidend: Wenn Regeln nur im Client sitzen, sind sie für Schnittstellen, Automatisierungen oder spätere Portale schwer konsistent zu halten.
Schnittstellenfähig werden: REST-API als kontrollierter Zugang, nicht als „zweiter Weg“
Viele Unternehmen brauchen Integration: Daten für BI, Anbindung an ERP/DMS/CRM, Automatisierung von Import/Export oder ein Kundenportal. Der typische Fehler ist, eine REST-API „daneben“ zu bauen, die direkt auf Tabellen zugreift, weil es schnell geht. Das erzeugt zwei Wahrheiten: Client-Logik und API-Logik divergieren, und Datenkonsistenz wird Zufall.
REST als Fassade vor stabilen Use-Cases
Eine REST-API (HTTP-basierte Schnittstelle, meist JSON) sollte fachliche Operationen anbieten, nicht Tabellen spiegeln. Beispiele sind: «crear comanda», «consultar estat», «pujar document a una operació». Die API ruft die gleichen Use-Cases auf, die auch der Client nutzt. Damit reduzieren Sie doppelte Regeln und schaffen eine klare Governance: externe Systeme bekommen einen kontrollierten Zugang, der versionierbar und absicherbar ist.
Sicherheit und Betrieb einer API
Aus B2B-Sicht sind weniger die Endpunkte spannend, sondern Betrieb und Absicherung:
- Autenticació: p. ex. procediments basats en tokens; en entorns empresarials sovint integració amb identitats centrals (SAML 2.0 és un estàndard estès per a l’inici de sessió únic).
- Autorització: permisos per operació, no només «pot utilitzar l’API».
- Limitacions de taxa i protecció contra l’abús: important per als accessos de socis.
- Versionament: canvis planificables sense ruptura silenciosa.
Si ja esteu planificant una modernització d’interfícies, val la pena considerar un enfocament estructurat per a incorporar una REST-API en programari existent: això facilita la priorització i redueix els riscos operatius.
Desplegament i capacitat d’actualització: el factor de cost silenciós
Molts sistemes Delphi no fallen per funcionalitat, sinó pels processos de desplegament. «Client-Server» vol dir en la pràctica: moltes estacions de treball, permisos heterogenis, ocasionalment servidors de terminal o Citrix, i a més ubicacions remotes amb VPN. Un sistema ordenat té una història d’actualització definida.
Estandarditzar: configuració, versions, entorns
Mesures típiques que tenen efecte immediat en el funcionament:
- Extreure la configuració del paquet binari: fitxers de configuració separats o fonts de configuració centrals, perquè les actualitzacions no sobreescriguin la configuració.
- Perfils d’entorn: Test, Staging, Producció amb punts finals de base de dades i serveis clarament separats.
- Instal·lació automatitzada: reproduible, també per a imatges de servidors de terminal.
Important: Encara que el client «només» sigui un programa d’escriptori, es beneficia d’una disciplina de llançament com la dels serveis de servidor: versionament amb registre de canvis, opcions de rollback i passos de migració definits.
Migracions de base de dades: planificables en lloc d’arriscades
Per a cada canvi estructural en taules, índexs o vistes cal tenir clar: quina versió de l’aplicació espera quin esquema? Un enfocament ordenat utilitza:
- Scripts de migració versionats per llançament
- Fases de transició retrocompatibles, quan el desplegament del client no pot fer-se simultàniament
- Estrategies clares de backout (còpia de seguretat, restauració, finestres de parada definides)
Això no és un fi en si mateix: sense aquesta disciplina, les millores d’arquitectura en el treball diari es consideren «massa perilloses» i queden aturades.
Logging, monitoring i cerca d’errors: sense telemetria no hi ha estabilitat
«Succeeix rarament, però quan passa, tot es para» és un senyal d’advertència. Els sistemes Client-Server madurats sovint tenen un logging insuficient, especialment a través de límits del sistema. Per als equips d’operacions és essencial que un cas d’error es pugui reconstruir tant temporalment com des del punt de vista tècnic.
Què s’hauria de registrar en la pràctica
- Correlació: una ID d’operació que connecti client, servei i operacions de base de dades
- Context: usuari, mandant, màquina/ubicació, versió, operació afectada
- Detalls tècnics: codis d’error de la base de dades, informació de temps d’espera, reintents
- Rellevant per a la seguretat: intents d’inici de sessió fallits, violacions de permisos, patrons d’accés sospitosos
És important la separació entre els logs tècnics i els protocols de naturalesa funcional. Un protocol funcional (p. ex. „Comprovant autoritzat per l’usuari X“) sovint és rellevant per a auditoria; els logs tècnics serveixen per a l’anàlisi d’errors i s’han de protegir i rotar en conseqüència.
Xarxa, seguretat i drets: De „funciona a la LAN“ a „funciona a l’empresa“
Molts Delphi-sistemes client-servidor es van dissenyar en èpoques en què „a la LAN“ equivalia a „de confiança“. Avui són estàndard la segmentació, els enfocaments Zero-Trust, VPN, MFA i regles de tallafoc restrictives. Ordenar l’arquitectura és, per tant, també feina de seguretat.
Drets de la base de dades: principi del mínim privilegi
Una situació antiga comuna és un usuari de base de dades amb permisos àmplies que utilitzen tots els clients. Millor és:
- Permisos basats en rols per àrea funcional
- Accessos separats per a client, serveis i tasques per lots
- Sense privilegis d’administrador en els accessos de producció per a operacions diàries
Això limita les conseqüències d’errors i fa que les auditories siguin clarament menys estressants. Alhora augmenten la transparència i la capacitat de diagnosi, perquè els errors de permisos ja no es produeixen „per casualitat“.
Secrets i configuració: Fora de les contrasenyes en text pla
Les credencials en fitxers INI o al Registry són un clàssic. Segons l’entorn, són opcions els magatzems de secrets centrals, la configuració xifrada o, com a mínim, conceptes d’operació amb permisos de fitxer restrictius. El decisiu és: la solució ha de continuar sent administrable. La seguretat que s’eludeix en el dia a dia no és seguretat.
Modernització pas a pas: Per on començar quan tot sembla important?
La priorització determina si la neteja s’atura després de dos mesos o si proporciona un alleujament mesurable. Ha demostrat ser eficaç una seqüència que tracta primer la seguretat operativa i després arrossega millores estructurals.
Un full de ruta pragmàtic per a la modernització
- Estabilitzar el comportament de transaccions i errors: menys corrupció de dades, menys „reparacions manuals“.
- Accés centralitzat a les dades: configuració de connexió unificada, timeouts, reintents, logging.
- Agrupar casos d’ús: extreure les operacions nuclears crítiques de la UI.
- Definir la interfície cap a l’exterior: REST-API o façana de servei per a la integració, sense exposar taules.
- Professionalitzar els desplegaments: actualitzacions reproduïbles, migracions de base de dades versionades.
- Hardening de seguretat: drets, secrets, límits de xarxa, capacitat d’auditoria.
Aquesta seqüència no és dogmàtica, però assegura que els passos inicials es notin de manera immediata en l’operació i que els passos posteriors siguin més senzills.
Obstacles típics des de la perspectiva del projecte – i com evitar-los
En l’ordenament, els projectes rarament fracassen per la tecnologia, sinó per condicions auxiliars. Alguns entrebancs apareixen especialment sovint:
„Treballs paral·lels“ sense xarxa de qualitat
Quan les mesures d’arquitectura s’executen paral·lelament als canvis funcionals, sovint falta una xarxa de seguretat. Com a mínim són necessaris: dades de prova reproduïbles, tests de smoke definits per als processos clau, i un procés de release que consideri el rollback no com una derrota, sinó com una eina operativa.
Dos models de dades simultanis
Qui construeix nous mòduls però manté que les velles pantalles accedeixin directament a les taules, aviat té regles inconsistents. Millor: definir regles de transició clares. O bé una àrea es manté temporalment „vella“ i no es modernitza en paral·lel, o bé es gestiona de manera consistent mitjançant la nova capa.
Integració sense governança
Un cop es connecten socis o sistemes interns, es generen dependències. Sense versionat, proves de contracte i una estratègia de deprecació definida, cada canvi es converteix en un bucle de coordinació. Això és menys un problema de desenvolupadors que un problema d’arquitectura i d’operacions.
Conclusió: Posar ordre significa tornar a fer manejables l’explotació i el canvi
Quan ordeneu arquitectures client-servidor en Delphi, no es tracta de «modern per ser modern». Es tracta d’estructurar una solució empresarial digital crítica per al negoci de manera que l’explotació, la seguretat i l’evolució es mantinguin planificables. Les palanques més efectives solen ser poc espectaculars: capes clares, accés a les dades coherent, límits de transacció nets, logging robust i una estratègia d’interfícies que no dupliqui regles.
El punt decisiu és l’enfocament: incremental, amb un model objectiu i una priorització que asseguri primer l’estabilitat. Així podeu modernitzar un entorn Delphi consolidat sense posar en perill l’operativa diària i sense ser empesos a un reinici complet i arriscat.
Si voleu avaluar pragmàticament els següents passos per a la vostra arquitectura, els accessos a la base de dades i les interfícies, parli amb nosaltres:
En l’àmbit tècnic, la Delphi Modernització també juga un paper important quan cal que integracions, fluxos de dades i evolució funcionin conjuntament i de manera neta.
Parli del projecte o iniciativa de modernització amb Net-Base.