Daudzas uzņēmējas gadiem vai pat desmitgadēm uztur stabilas Delphi lietojumprogrammas, kas attēlo viņu procesu kodolu: pasūtījumu apstrādi, ražošanu, servisu, loģistiku, norēķinus, iekārtu pārvaldību, dokumentu darplūsmas. Šajās sistēmās nav tikai kods, bet arī izturīga sadarbība starp biznesa noteikumiem, datu modeli, lietotāja vadību un ekspluatācijas pieredzi. Tieši tas padara modernizāciju par izaicinājumu: patiesā vērtība reti atrodas lietotāja saskarnē, bet gan pieaugušajā biznesa loģikā.
Ja modernizāciju saprot kā „jaunu izstrādi“, zaudējums ir ieprogrammēts. Ne tāpēc, ka jaunās tehnoloģijas pašas par sevi būtu sliktas, bet tāpēc, ka implícītās zināšanas no vecās sistēmas – īpašie gadījumi, vēsturiskie dati, procesa izņēmumi, regulatīvās nianses – pārvietošanas laikā bieži netiek pilnībā rekonstruētas. Rezultātā rodas dārgas regresijas kļūdas, mainīti procesa laiki, pieņemšanas problēmas un projekts, kas ilgst ilgāk nekā plānots.
Taču Delphi ir labi modernizējams, nezaudējot biznesa loģiku. Atslēga ir kontrolēta, pakāpeniska pieeja: vispirms radīt caurspīdīgumu (arhitektūra, dati, riski), pēc tam atdalīt (UI, datu piekļuve, domēna loģika), vēlāk modernizēt (datubāzu draiveri, Unicode/64-Bit, API, servisi, multiplatforma) — vienlaikus nodrošinot nepārtrauktu darbību. Šis raksts apraksta praksē pārbaudītus modernizācijas modeļus, tipiskas ķibeles un rīcības kārtību, kas strādā B2B vidē ar augstu procesa kritiskumu.
Kāpēc Delphi modernizācija reti ir tikai „tehniskais projekts“
Realitātē modernizācijas neizdodas nevis trūkstoša kompilatora karodziņa dēļ, bet nepareizu pieņēmumu dēļ par sistēmas uzvedību. Delphi lietojumprogrammas, kuras gadu gaitā ir paplašinātas, bieži satur:
- Biznesa noteikumus GUI notikumos (OnClick, OnExit, OnValidate), bieži sadalītus pa daudzām formām
- SQL vaicājumus „tuvu saskarnei“, kas gadiem optimizēti tieši vienai datubāzei
- Apvedceļus vēsturiskiem datiem, īpašiem gadījumiem, klientu variantiem vai daudzlietotāju loģikai
- Partiju procesus, kas praksē tiek palaisti fiksētos laikos un kam ir atkarības
- Integrācijas ar ERP, DMS, CRM vai iekārtām, kas gandrīz nav dokumentētas
- Tumšās zināšanas ekspluatācijas rutīnās: „Ja kļūda X, vispirms pārbaudīt Y“
Ja šeit sākt ar Big-Bang pārrakstīšanu, viss šis zināšanu kopums jāatjauno no jauna — ieskaitot kļūdas, ko vecā risinājuma ilgi vairs nerada. Labāka pieeja ir attiekties pret biznesa loģiku kā aktīvu: vispirms to izolēt, pēc tam nodrošināt, un tikai tad modernizēt.
Modernizācija bez loģikas zuduma: mērķa aina un pamatprincipi
Ilgtspējīgs mērķa attēls B2B sistēmām nav „viss jauns“, bet arhitektūra, kas ļauj izmaiņas. Tipiskas īpašības:
- Atšķirtas atbildības (UI, domēns/biznesa loģika, datu piekļuve, integrācijas)
- Testējamība un mērojamība (regresijas testi, žurnāldati, monitoring, reproducējamas būves)
- Pakāpeniska aizvietojamība (UI modernizēt bez tūlītējas datu modeļa pārbūves; DB migrēt bez UI pārrakstīšanas)
- API spēja (REST-serveris vai servisa slānis, lai pieslēgtu portālus, mobilās lietotnes, integrācijas)
- Ekspluatācijas spēja (Windows- un Linux-pakalpojumi, skaidri izvietošanas modeļi, atgriešanās stratēģija)
Delphi gadījumā tas ir īpaši sasniedzams, jo esošās vienības un domēna klases var turpināt izmantot, kamēr ārpusē tiek modernizēts: datu piekļuve no BDE uz BDE-Ablösung ar natīvu pieslēgumu, jauni REST galapunkti, jauni UI moduļi, jauni izvietojumi.
Inventarizācija: kas patiešām jāuztur?
Pirms koda „saskāriena“ ir vērts veikt strukturētu inventarizāciju. Mērķis nav pilnīga dokumentācija, bet uzticams lēmumu pieņemšanas bāze.
1) Biznesa loģikas karte, nevis koda lasīšanas maratons
Praksē labi strādā biznesa loģikas karte ar šādiem skatpunktiem:
- Lietojuma gadījumi: Kuri kodolprocesi ir kritiski uzņēmējdarbībai? (piem., pasūtījuma izveide, rēķins, stornēšana, atgriešana, iekārtu serviss, apkalpošanas līgums)
- Noteikumi: Kādas validācijas, aprēķini, stāvokļu mehānismi pastāv?
- Varianti: Daudzlietotāju režīmi, klientu konfigurācijas, valstu specifiskie noteikumi
- Saskarnes: Import/eksports, ERP/DMS/CRM, iekārtas/protokoli
- Partijas/uzdevumi: nakts skripti, atskaites, datu saskaņošana
No šīs kartes izriet prioritizēti modernizācijas paketi: kas jāstāda stabili, kas drīkst mainīties, kas var nākt vēlāk.
2) Tehnisko parādu padarīt redzamu
Tipiski tehniskie parādi vecākās Delphi sistēmās:
- Borland BDE/Paradox atkarības
- ANSI virknes/trūkst Unicode migrācijas
- Tikai 32-Bit, novecojušas trešo pušu komponentes
- Monolītiska formu loģika, globālas mainīgās, blakus efektu bagātas vienības
- Neskaidras transakciju robežas un „SQL visur“
Māksla nav šos punktus dogmatiski „izlabot“, bet sakārtot secībā, kas minimizē risku un maksimizē biznesa vērtību.
Arhitektūras atdalīšana: sviras pret loģikas zudumu
Biežākais loģikas zuduma iemesls ir UI, datu piekļuves un biznesa noteikumu sajaukums. Tāpēc modernizācija sākas ar atdalīšanu — nevis ar „jaunu UI ietvaru“.
Layer-3 arhitektūra kā pragmatisks mērķstāvoklis
Daudzām Delphi esošajām lietojumprogrammām labi darbojas Layer-3 arhitektūra:
- Presentation Layer: VCL/FMX formu slānis, ViewModels/Presenter, validācija tikai UI-līmenī (formāts, obligātie lauki)
- Business Layer: domēna modeļi, servisi, noteikumi, stāvokļa loģika, aprēķini
- Data/Integration Layer: repozitoriji, SQL/ORM daļas, saskarnes adapteri, REST klienti, ziņojumapmaiņa
Priekšrocība: biznesa loģika kļūst testējama un atkārtoti izmantojama. Vēlāk klientu portāls, REST-serveris vai Linux pakalpojums var izmantot tieši tās pašas domēna servisu implementācijas. Tā jūs modernizējat “ārējo apvalku“, nezaudējot kodolu.
Strangulation Pattern: vecās sistēmas pakāpeniska „apņemšana“
Viens pārbaudīts migrācijas modelis ir Strangulation Pattern: jaunas funkcijas jau tiek radītas jaunajā struktūrā (piem., domēna serviss + repozitorijs), kamēr esošās formas tiek pakāpeniski pārveidotas. Vecā pasaule paliek darbspējīga, bet to soli pa solim aizstāj jaunā.
Svarīgi aktīvi mainīt atkarības: nevis „forma izsauc SQL“, bet „forma izsauc servisu“, un serviss lemj. Šī nelielā inversija bieži ir lielākais ieguvums.
Datu piekļuve modernizēt: BDE-Ablösung un FireDAC rūpīga plānošana
Viena centrāla modernizācijas darbība ir BDE-Ablösung. Uzņēmumi nereti novērtē par zemu, ka runa nav tikai par draiveriem, bet par SQL semantiku, transakcijām, bloķēšanu, datu tipiem un kļūdu uzvedību. Mūsdienu Delphi steki parasti balstās uz BDE-Ablosung mit nativer Anbindung ar natīvajiem draiveriem (piem., MariaDB/MySQL, PostgreSQL, SQL Server).
Kas patiesi jāizlemj pārejas laikā
- Datubāzes mērķis: Vai paliek pie esošās DB? Vai datubāzes pārbūve ir jēgpilna (piem., no Paradox/Firebird uz MariaDB vai PostgreSQL)?
- Transakciju modelis: Kur sākas/beidzas transakcijas? Kuri lietojuma gadījumi jāveic atomiski?
- Sekmīgums/bloķēšana: optimistiska vs pesimistiska pieeja, deadlock apstrāde, atkārtošanas stratēģijas
- SQL dialekts: datuma funkcijas, virkņu uzvedība, NULL apstrāde, lielo/būlais sensitivitāte
- Veiktspēja: indeksi, vaicājumu plāni, strādāšana ar lapošanas mehānismiem, masīvie ievietojumi
Biznesa loģika cieši saistīta ar datu uzvedību. Ja migrāciju veic „pa ceļam“, praksē riskē ar smalkām novirzēm: noapaļošanas atšķirībām, kārtošanu, datuma robežām, bloķēšanas konfliktiem. Tāpēc datu slānim jābūt modernizācijas plānā agri — ieskaitot migrācijas ceļu un testdatu stratēģiju.
Pragmatiski soļi uz FireDAC migrāciju
Nevis pārrakstīt visu lietojumprogrammu vienā piegājienā, bet šāda secība ir pārbaudīta:
- Ievieš datu piekļuves slāni (Repository/DAO) kā fasādi
- Pārslēdz atsevišķus lietojuma gadījumus uz FireDAC (piem., „lasīšana“ pirmajā kārtā, „rakstīšana“ vēlāk)
- Vienotina savienojumu apstrādi, kļūdu apstrādi, žurnāldatu vākšanu
- Pakāpeniski izslēdz BDE komponentes, kur fasāde ir stabila
Tādējādi lietojumprogramma jebkurā brīdī paliek piegādājama, un jūs izvairāties no ilgstoša „daļēji pabeigta“ posma.
Unicode, 64-Bit un atkarības: modernizācijas slazdi detaļās
Daudzas modernizācijas neizdodas ne koncepcijas dēļ, bet nenovērtētu detaļu dēļ. Trīs no tām Delphi projektos ir īpaši izplatītas.
Unicode migrācija: ne tikai virknes, bet datu plūsmas
Ļoti vecās Delphi versijās sistēmas nāk no ANSI pasaules. Unicode migrācija skar:
- Virknju tipus un konvertācijas (WideString/AnsiString/UnicodeString)
- Failu un ceļu apstrādi (Windows-API, tīkla ceļi)
- Importu/eksportu (CSV, fiksētas lauka garums, EDI, mantošanas saskarnes)
- Kārtošanu/kollāciju datubāzē
Svarīgi identificēt kritiskās datu plūsmas (piem., rēķinu teksti, preču nosaukumi, starptautiskas adreses) un izveidot regresijas testus šiem gadījumiem. Unicode nav tikai “pārbūve”, bet konsekvents kvalitātes process.
64-Bit pāreja: atmiņa nav vienīgais temats
64-Bit pāreju bieži reducē līdz rādītāju izmēriem. Praktiski svarīgākie jautājumi ir:
- Novecojušas trešās puses komponentes bez 64-Bit atbalsta
- COM/ActiveX atkarības
- DLL un draiveri (svītrkodu lasītāji, iekārtas, kriptogrāfija, paraksti)
- Instalētāji/izvietošana un reģistra ceļi (WOW64)
Saprātīga stratēģija ir vispirms inventarizēt ārējās atkarības un definēt alternatīvas. Tad 64-Bit solis kļūst plānojams — un nepārsteigs īsi pirms izlaiduma.
Windows 11 ARM64: pārbaudīt agri, nevis maksāt vēlāk
Ar Windows 11 ARM64 parādās jauna mērķsistēmu klase. Pat ja ne katram uzņēmumam uzreiz nepieciešamas natīvas ARM64 būves, ir saprātīgi to pārbaudīt laikus:
- Vai pastāv natīvas atkarības (DLL, draiveri), kas uz ARM64 nedarbosies?
- Vai lietojumprogramma paļaujas uz emulāciju, un vai tas ir pieņemami?
- Kāds ir instalētāja un atjauninājumu/novēršanas process?
Modernizācijas projektos tas bieži ir „vēls“ temats, kas tad kļūst dārgs. Labāk: iekļaut platformas ceļkartē un tehniski precizēt agri.
REST-serveris un pakalpojumi: padarīt biznesa loģiku pieejamu portāliem un integrācijām
Daudzi uzņēmumi ne tik daudz modernizē Delphi tāpēc, ka darbvirsmas lietotne izskatās veca, bet gan jo rodas jaunas prasības: klientu portāls, partneru piekļuve, mobilie procesi, integrācija ar ERP/DMS/CRM, atskaišu plūsmas. Tam nepieciešamas skaidras saskarnes. REST-serveris bieži ir vispraktiskākā tilta risinājums.
API vispirms? Tikai, ja tiesības un domēna loģika nāk līdzi
API ir lietderīgs tikai tad, ja tajā tiek īstenota tā pati biznesa loģika kā klientā. Citādi rodas divas noteikumu kopas: viena darbvirsmā, otra backendā. Sekas ir nekonsistences un drošības caurumi.
Tāpēc REST-servera slānī vajadzētu pēc iespējas tiešāk balstīties uz domēna servisiem. Tipiskie elementi:
- Autentifikācija/autorizācija (lomas, daudzlietotājības režīmi, piekļuves tiesības)
- DTOs/serializācija ar skaidriem versiju noteikumiem
- Transakciju un kļūdu koncepts (HTTP statusi, Problem-Details, žurnāldati)
- Idempotence un blakussinhronitāte (atkārtojumiem, rindu apstrādei)
Tādējādi REST-serveris kļūst par stabilu integrācijas punktu — nevis par „otro klientu“.
Linux-pakalpojumi un Windows servisi modernizēt
Partiju procesi un integrācijas daudzviet tiek darbinātas kā Windows servisi, Task Scheduler uzdevumi vai pat „slēptas“ darbvirsmas instance. Modernizācijas laikā vērts konsolidēt:
- Atskirt UI no fona loģikas
- Konfigurējami izpildes grafiki un skaidri ekspluatācijas parametri
- Skaidra žurnāldatu vākšana (strukturēti logi, korelācija uz katru job/vaicājumu)
- Iespēja darbināt servisu zem Linux (piem., konteinerizētai izvietošanai)
Priekšrocība nav tikai „mūsdienīga“, bet operacionāla: reproducējama darbība, mazāk manuālu iejaukšanos, labāka kļūmju meklēšana.
UI modernizēt, neķeroties pie koda kodola: VCL, FMX un hibrīdie risinājumi
Daudzi modernizācijas plāni sākas ar UI. Tas var būt pamatoti — ja vien skaidri apzinās, ko tas dod. Ja biznesa loģika ir atdalīta, UI risku var ievērojami samazināt atjaunojot tikai saskarni.
VCL lietojumprogrammu pakāpeniska modernizācija
VCL daudzās B2B situācijās joprojām ir robusta izvēle, īpaši ekspluatācijas-intensīvām darbvirsmas vidēm ar augstu produktivitāti. Modernizācija var nozīmēt:
- Samazināt UI loģiku (Presenter/ViewModel), biznesa noteikumus pārvietot uz servisiem
- Sakārtot komponentu ainavu, konsolidēt pašizstrādātas kontroles
- Uzlabot atsaucību (Async, fona uzdevumi, progress, Cancel)
- Pieejamāku lietošanu, konsekventu validāciju, saprotamākas kļūdu ziņas
Tas sniedz jūtamu labumu, nezaudējot nepieciešamību pārrakstīt visu saskarni.
Delphi Multiplatforma: kad FMX ir jēga
Ja ir reālas multiplatformas prasības (Windows, macOS, iespējams Linux servisu kontekstā), FMX var būt opcija. Izšķiroša ir sagaidāmā pielietošana: multiplatforma nozīmē papildu testēšanas un integrācijas darbu (fonti, drukāšana, OS dialogi, failu sistēma, pakotne/izvietošana). Izmaksas ir labi aprēķināmas, ja biznesa loģika jau atrodas tīrā slānī.
Bieži pragmatisks ceļš ir hibrīds: VCL paliek Windows klientam, kamēr jaunas frontes (portāls, mobilā lietotne) tiek būvētas caur REST-serveri. Tādējādi multiplatforma tiek sasniegta pāri sistēmas robežām, nevis ar vienu UI steku.
Testēšana un regresija: kā „nofiksēt“ biznesa loģiku
„Biznesa loģikas zaudēšana“ praksē nozīmē: sistēma robežapstākļos dod citus rezultātus. Tas reti ir uzreiz pamanāms, bet dārgs. Tāpēc testējamība nav greznība, bet modernizācijas instruments.
Zelta lietojuma gadījumi un referencedati
Strādā komplekts ar „zelta“ lietojuma gadījumiem: reāli, kritiski procesi ar definētu datu stāvokli un gaidāmiem rezultātiem (piem., virkne no piedāvājuma līdz kredītam, vai apkopes uzdevums ar rezerves daļām un darba uzskaiti). Tos ievieš kā regresijas testus vai vismaz kā reproducējamus testu skriptus.
Svarīgi: ne tikai veiksmīgas plūsmas, bet arī tipiskie kļūdu ceļi (bloķēšanas konflikti, trūkstošas tiesības, nepilnīgi pamata dati, dublikātu importa faili).
Automatizēt tur, kur ir lielākais sviras efekts
Ne katram esošajam projektam uzreiz vajadzīga 80% unit testu pārklājums. Augsts ROI bieži rodas šādās vietās:
- Domēna servisi (aprēķini, noteikumi, stāvokļu maiņa)
- Datu piekļuve ar skaidriem kontraktiem (mapping, SQL, transakcijas)
- API testi (autentifikācija, tiesības, versionēšana)
Mērķis ir stabilitāte pie izmaiņām, ne akadēmiski rādītāji.
Rīcības modelis praksē: modernizācijas ceļvedis etapos
No B2B skatpunkta modernizācijai jāpaliek piegādājamai. Tipisks ceļvedis, kas orientēts uz risku:
Etaps 1: Analīze, mērķarhitektūra, Quick Wins (2–6 nedēļas)
- Sistēmas karte (moduļi, datubāzes, saskarnes, uzdevumi, atkarības)
- Risku matrica (BDE, trešās puses, 32/64-Bit, Unicode, izvietošanas jautājumi)
- Mērķarhitektūras definīcija (Layer-3, servisu slānis, API stratēģija)
- Quick Wins: būves procesa stabilizācija, žurnāldatu uzlabošana, versiju vadības sakārtošana
Etaps 2: Biznesa loģikas atdalīšana (pastāvīgi, inkrementāli)
- Identificēt domēna servisus un izdalīt tos no formām
- Ievieš repozitoriju fasādes
- Pirmie regresijas testi kritiskiem lietojuma gadījumiem
Etaps 3: Datu piekļuve/DB slāņa modernizācija
- Ievieš FireDAC, izstrādā savienojumu un transakciju konceptu
- BDE-Ablösung pa modulēm (vai datubāzes migrācija paralēlā darbībā)
- Veiktspējas un bloķēšanās uzvedības testi slodzē
Etaps 4: REST-serveris un integrācijas
- API ar autentifikāciju, piekļuvēm, versiju pārvaldību
- Pieslēgt portālus/integrācijas bez dubultas loģikas
- Konsolidēt partiju un fona procesus kā pakalpojumus
Etaps 5: Platformas un UI lēmumi (64-Bit, ARM64, multiplatforma)
- 64-Bit būve, atkarību aizvietošana
- ARM64 saderības pārbaude/plānošana
- UI modernizācija: VCL atsvaidzināšana vai FMX/hibrīds, balstoties uz biznesa ieguvumu
Secība ir apzināti izvēlēta tā, lai agri iegūtu caurspīdīgumu, pēc tam stabilizētu kodolu un tikai pēc tam plaši izplatītu „redzamas“ izmaiņas. Tā samazinās risks un darbība paliks plānojama.
Tipiski anti‑patterni: kas padara modernizācijas dārgas
Daži modeļi auditos un glābšanas projektos parādās atkārtoti:
- „Mēs būvējam no jauna un pārņemam tikai funkcijas“: gandrīz vienmēr noved pie loģikas zuduma, jo trūkst īpašo gadījumu.
- API kā paralēla pasaule: biznesa noteikumi paliek klientā un backendā tiek izgudroti no jauna.
- Datubāzu maiņa bez semantikas testiem: dati vienādi, bet uzvedība atšķiras (NULL, kārtošana, datuma loģika).
- Atkarību vadības par vēlu: 64-Bit/ARM64 saplīst pie mazas DLL īsi pirms Go‑Live.
- „Refaktors pirmais“ bez mērķa bildes: daudzas izmaiņas, maz mērāma ieguvuma, liela regresija.
Pretargumentācija vienmēr ir tā pati: vispirms skaidri definēt mērķarhitektūru un riskus, pēc tam inkrementāli pārbūvēt, vienlaikus testējot un padarot biznesa loģiku redzamu.
Kopsavilkums: modernizēt nozīmē saglabāt — un mērķtiecīgi paplašināt
Modernizēt Delphi bez biznesa loģikas zaudēšanas nav pretruna, bet disciplīna. Uzņēmumiem nav jāizvēlas starp „viss saglabāt“ un „viss aizstāt“. Ar skaidru arhitektūras atdalīšanu (piem., Layer-3), kontrolētu BDE-Ablösung uz FireDAC, API stratēģiju caur REST-serveri un skaidru plānu Unicode, 64-Bit un jaunu platformu kā Windows 11 ARM64 apskatei, pieaudzis sistēmas kodols pakāpeniski pārvēršams par ilgtspējīgu struktūru.
Izšķirošais ir attiekties uz biznesa loģiku kā kodolaktuīvu: izolēt, padarīt testējamu, tikai pēc tam modernizēt. Tā rodas arhitektūra, kas atbalsta portālus, servisus un multiplatformas prasības, nezaudējot ekspluatācijas drošību.
Ja plānojat Delphi Modernisierung un vēlaties sakārtot biznesa loģiku, datu piekļuvi un ekspluatāciju reālistiskā migrācijas ceļā, sazinieties ar mums, lai pārrunātu iespējamo migrācijas plānu: https://net-base-software-gmbh.de/kontakt/