Technológiai profil
Technikai alapjaink áttekintése
A technológiákat nem divat alapján választjuk, hanem az üzemeltetési valóság, az élettartam, az integrációs igény és a csapatban való működőképesség szerint. Nem a hívószó a döntő, hanem az, hogy a rendszer később tisztán üzemeltethető, bővíthető és átvehető marad-e.
Erős az üzleti logikában és a többplatformos kliensekben
Delphi ott erős, ahol a felhalmozott üzleti logikát, az adatbázis-közeli folyamatokat, riportokat és a stabil klienseket Windows, macOS és Linux platformokra hosszú távon tovább kell vinni.
Delphi megtekintése
C#
Erős REST-hez, szolgáltatásokhoz és portálokhoz
C#-t akkor használunk, ha 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égteher 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 kelljen az állomány ellenében felépíteni.
Layer-3 megtekintése
Platformok
Windows 11 ARM64 azonnali bevonása a tervezésbe
A klasszikus x64 célok mellett korán figyelembe vesszük az aktuális platformokat, például a Windows 11 ARM64-t, 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,
- az összetett desktop folyamatoknak stabilnak kell maradniuk,
- Windows-, macOS- és Linux-klienseknek közös szakmai alapra épülve kell létrejönniük.
C# akkor ésszerű, ha
- REST-szervereket és szolgáltatásokat építünk fel,
- az API-k és a külső integrációk állnak a fókuszban,
- modern szolgáltatás-architektúrákra van szükség.
A 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ésenként, Layer-3-struktúraként kell 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 ténylegesen a rendszer, milyen folyamatokat hordoz, hol szakadnak meg az adatáramlások, és mely örökségterhek lassítják az üzemeltetést. Ebből egy olyan modernizációs útvonal áll össze, amely nemcsak papíron tűnik tisztának, hanem a mindennapokban is életképes marad.
Sok, hosszú évek alatt kinőtt alkalmazásban a valódi érték nem a felületben, hanem a szakmai logikába beépült években, speciális szabályokban, kivételekben és tapasztalati tudásban rejlik. Ezt a szubsztanciát nem dobja el az ember könnyelműen. Tisztán szétválasztjuk a felelősségeket, újrarendezzük az adatbázist, kiváltjuk a régi hozzáférési útvonalakat, új REST-interfészeket hozunk létre, és szükség esetén ugyanarra a szakmai alapra építve klienseket egészítünk ki Windows, macOS és Linux számára. Így nem egy kemény törés jön létre, hanem egy követhető továbbfejlesztés, világos technikai lehatárolással.
Gyakran ez azt is jelenti, hogy a történetileg kialakult monolitokat újra olyan formába hozzuk, amely karbantarthatóvá, tesztelhetővé és bővíthetővé válik. Az adatelérést stabilizáljuk, az üzleti logikát leválasztjuk a felületi kódról, az interfészek tervezhetővé válnak, és a jövőbeli bővítésekért nem kell többé a meglévő állománnyal szemben megküzdeni. 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.
Szolgáltatások és szerverek ugyanannak az architektúrának a részeként
Sok vállalati rendszernek ma már nem csak egy kliensre van szüksége, hanem háttérszolgáltatásokra, Windows- vagy Linux-szolgáltatásokra és REST-szerverekre is. Pontosan ezért ezeket a részeket nem utólagos hozzáépítésként, hanem ugyanannak az architektúrának a részeként tervezzük. Egy szolgáltatás, amely csak később „valahogy” kerül hozzá, 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ítve a háttérben kell végrehajtani, akkor a technikai felelősséget a kezdetektől 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 a állapotváltozások; hogyan marad konzisztens a szakmai logika? Ezekre a kérdésekre korán választ adunk, hogy az egyes építőelemekből teherbíró, egységes rendszer álljon össze.
Ez különösen multiplatform projekteknél döntő. Egy desktop kliens Windows, macOS vagy Linux alatt szakmailag nem jelenthet mást, mint egy kísérő REST-szerver vagy egy háttérszolgáltatás. Ezért az adatmodellt, a folyamatokat, a jogosultságokat, az integrációkat és az üzemeltetést mindig együtt gondoljuk. Így olyan architektúra jön létre, amelyben a kliensek, szolgáltatások és szerverek ugyanazt a nyelvet beszélik.
Alapelvünk
A technológia számunkra nem hitrendszer. Az a döntő, hogy az architektúra, a csapatban való működés, 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 értelmesen kézben tartható.
Egyes feladatokat tudatosan Delphi-val oldunk meg, mert ott a hosszú idő alatt kialakult üzleti logika, a nagy teljesítményű kliensek és a multiplatform képesség jól érvényesülnek. Más igé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 tisztánlátásból: melyik rendszerkomponens milyen felelősséget visel, milyen élettartam várható, mekkora a csapat, mennyire kritikus az üzemeltetés, és milyen bővítések fognak a következő években reálisan megjelenni?
Számunkra itt kezdődik a professzionális szoftverfejlesztés. Nem csak olyasmit szeretnénk leszállítani, ami ma működik, hanem olyan technikai 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 érdemes a Delphi egy teljes újraplatformozással szemben?
Mindig akkor, ha a kialakult szakterületi logikát, a nagy teljesítményű desktop-folyamatokat és a multiplatform célokat gazdaságosan tovább lehet vinni, ahelyett hogy a meglévő alapot könnyelműen lecserélnénk.
Mikor alkalmazzák kiegészítésként a C#?
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 az 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őbeni platformváltásokat.
Korán számolnak 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 egyedi projektek.
További kérdések összegyűjtve
Ezek a rövid válaszok itt maradnak az oldalon. A központi FAQ landing oldalon a témát kiegészítésként összefüggésbe helyezzük az architektúrával, a modernizációval, a platformokkal és az üzemeltetéssel.