Technológiai profil
Technikai alapjaink áttekintése
A technológiákat nem divat alapján választjuk, hanem az üzemeltetési realitás, az élettartam, az integrációs igény és a csapat kompetenciái szerint. Nem a buzzword dönt, hanem az, hogy a rendszer később tisztán üzemeltethető, bővíthető és átadható marad-e.
Erős üzleti logikában és többplatformos kliensekben
Delphi ott erős, ahol a felhalmozódott üzleti logikát, adatbázis-közeli folyamatokat, riportokat és stabil klienseket Windows, macOS és Linux számára hosszú távon tovább kell vinni.
Delphi megtekintése
C#
Erős REST-ban, szolgáltatásokban és portálokban
C#-t akkor használjuk, amikor portálokat, modern backend szolgáltatásokat, REST-API-kat és integrációkat kell tisztán a meglévő vállalati rendszerekhez illeszteni.
C# megtekintése
Architektúra
Layer-3 a monolitikus örökség helyett
Tudatosan szétválasztjuk a felületet, az üzleti logikát és az adatelérést, hogy a változtatások tervezhetők maradjanak, és az új szolgáltatásokat ne a meglévő állomány ellenében kelljen felépíteni.
Layer-3 megtekintése
Platformok
Windows 11 ARM64 átgondolása az elejétől
A klasszikus x64 célok mellett a Windows 11 ARM64-hoz hasonló aktuális platformokat is korán figyelembe vesszük, hogy az új hardver és a telepítések később ne váljanak külön projektté.
ARM64 megtekintése
Mikor melyik irány ésszerű
Delphi akkor ésszerű, ha
- a meglévő szakmai logikának tovább kell élnie,
- a komplex desktop folyamatoknak stabilnak kell maradniuk,
- Windows-, macOS- és Linux-klienseket közös szakmai alapra kell építeni.
C# akkor ésszerű, ha
- REST-szerverek és szolgáltatások épülnek,
- az API-k és a külső integrációk állnak a középpontban,
- modern szolgáltatás-architektúrákra van szükség.
Hibrid akkor ésszerű, ha
- a meglévő alkalmazásoknak és az új portáloknak együtt kell működniük,
- a desktop, a szolgáltatások és a web ugyanazt az adatbázist használja,
- a modernizáció lépésről lépésre, és Layer-3-struktúraként kell hogy megvalósuljon.
Delphi-modernizáció a gyakorlatban
Ha egy régi Delphi-alkalmazás szakmailag még értékes, nem modernizálunk vakon. Először elemezzük, hogyan működik a rendszer a valóságban, milyen folyamatokat tart, hol törnek meg az adatáramlások, és milyen örökség terhek lassítják az üzemeltetést. Ebből egy modernizációs útvonal áll össze, amely nem csak papíron tűnik tisztának, hanem a mindennapokban is működőképes marad.
Sok, hosszú évek alatt kinőtt alkalmazásnál a tényleges érték nem a felületben van, hanem az évek során felhalmozott üzleti logikában, speciális szabályokban, kivételekben és tapasztalati tudásban. Ezt a lényeget nem dobja ki az ember könnyelműen. Tisztán szétválasztjuk a felelősségi köröket, újrarendezzük az adatbázist, kiváltjuk a régi elérési utakat, új REST-interfészeket hozunk létre, és igény szerint ugyanarra a szakmai alapra építve kiegészítjük kliensekkel Windows, macOS és Linux számára. Így nem kemény törés, hanem követhető továbbfejlesztés jön létre világos műszaki metszettel.
Gyakran ez azt is jelenti, hogy a történetileg kinőtt monolitokat ismét olyan formába hozzuk, amely karbantarthatóvá, tesztelhetővé és bővíthetővé válik. Stabilizáljuk az adatelérést, leválasztjuk az üzleti logikát a felületkódról, tervezhetővé tesszük az interfészeket, és a jövőbeli bővítéseknek többé nem kell a meglévő állapottal szemben kivívniuk a helyüket. A cél nem kozmetikai modernizálás, hanem egy olyan rendszer, amely ismét mozgásteret ad a vállalatnak az új igényekhez.
Services és szerverek ugyanannak az architektúrának a részeként
Sok vállalati rendszernek ma már nemcsak kliensre van szüksége, hanem háttérszolgáltatásokra, Windows- vagy Linux-services komponensekre és REST-szerverekre is. Pontosan ezért ezeket a részeket nem utólagos toldásként tervezzük, hanem ugyanannak az architektúrának a részeként. Egy service, amely csak később valahogy „hozzákerül”, szinte mindig kivételes esetté válik.
Ha az adatokat elosztva kell feldolgozni, interfészeket kell biztosítani, exportokat kell futtatni, importokat kell felügyelni, vagy feladatokat időzítetten, háttérben kell végrehajtani, akkor a műszaki felelősséget kezdettől fogva tisztázni kell. Mely részek futnak a kliensben, melyek a szolgáltatásban, melyek a szerveren, hogyan válnak láthatóvá a hibák, hogyan követhetők az állapotváltozások, hogyan marad konzisztens az üzleti logika? Ezekre a kérdésekre korán válaszolunk, hogy az egyes építőelemekből terhelhető, megbízható teljes rendszer álljon össze.
Ez különösen multiplatform projektekben döntő. Egy Windows, macOS vagy Linux alatti desktop-kliens szakmailag nem jelenthet mást, mint a kísérő REST-szerver vagy egy háttérszolgáltatás. Ezért az adatmodellt, folyamatokat, jogosultságokat, integrációkat és az üzemeltetést mindig együtt gondoljuk végig. Így olyan architektúra születik, amelyben a kliensek, services komponensek és szerverek ugyanazt a nyelvet beszélik.
Alapelvünk
A technológia számunkra nem hitrendszer. A döntő az, hogy az architektúra, a csapatban való megvalósíthatóság, az üzemeltetés és a jövőbeli bővítések illeszkedjenek a vállalathoz. Nem a leghangosabb platform nyer, hanem az, amellyel a kockázat, a karbantarthatóság és a növekedés ésszerűen irányítható.
Egyes feladatokat tudatosan Delphi-val oldunk meg, mert ott a meglévő üzleti logika, a nagy teljesítményű kliensek és a multiplatform képesség ki tudják használni az erősségeiket. Más követelmények jobban illenek C#-hez, szolgáltatásokhoz, egy portálhoz vagy a kettő kombinációjához. A jó architektúra nem divatból születik, hanem tisztaságból: melyik rendszerkomponensnek mi a felelőssége, milyen élettartam várható, mekkora a csapat, mennyire kritikus az üzemeltetés, és milyen bővítések várhatók reálisan a következő években?
Számunkra itt kezdődik a professzionális szoftverfejlesztés. Nemcsak olyasmit akarunk szállítani, ami ma működik, hanem olyan műszaki alapot teremteni, amely később is követhető, átvehető és gazdaságosan karbantartható.
Gyakori kérdések a technológiáról és az architektúráról
A technológiai döntéseknek illeszkedniük kell a csapathoz, a szakterülethez és az üzemeltetéshez. Éppen ezért ezeket a kérdéseket nem elvontan tisztázzuk, hanem mindig a konkrét rendszeren.
Mikor ésszerűbb a Delphi egy teljes újraplatformozással szemben?
Mindig akkor, amikor a felépült üzleti logikát, a nagy teljesítményű desktop folyamatokat és a multiplatform célokat gazdaságosan tovább kell vinni, ahelyett hogy a meglévő értéket könnyelműen lecserélnénk.
Mikor vetik be kiegészítésként a C#-t?
Elsősorban portálokhoz, webes back-endekhez, REST-szolgáltatásokhoz, integrációkhoz és olyan szolgáltatásorientált architektúraelemekhez, amelyek jól összehangolhatók a meglévő desktop rendszerekkel.
Mennyire fontos a Layer-3 a gyakorlatban?
Nagyon. Csak a UI, az üzleti logika és az adatelérés tiszta szétválasztása teszi kezelhetővé a modernizációt, a tesztelést, a szolgáltatásokat és a jövőbeli platformváltásokat.
Korán számolnak az olyan új platformokkal, mint a Windows 11 ARM64?
Igen. Az új célhardvert és a deployment útvonalakat korán megvizsgáljuk, hogy később ne váljanak belőlük költséges különprojektek.
További kérdések összegyűjtve
Ezek a rövid válaszok itt az oldalon maradnak. A központi FAQ landing oldalon a témát kiegészítően összefüggésbe helyezzük az architektúrával, a modernizációval, a platformokkal és az üzemeltetéssel.