Nem divat szerint választunk technológiákat, hanem az üzemeltetési valóság, az élettartam, az integrációs igény és a csapatképesség alapján. Nem a divatos kifejezés a döntő, hanem az, hogy a rendszer később tisztán üzemeltethető, bővíthető és átvehető marad-e.
Erős üzleti logika és többplatformos kliensalkalmazásokhoz
Delphi ott erős, ahol a kialakult üzleti logika, az adatbázis-közeli folyamatok, a riportok és a stabil kliensalkalmazások Windows, macOS és Linux számára hosszú távon folytatandók.
Delphi megtekintése
C#
Erős REST, szolgáltatások és portálok esetén
C#-t használunk, ha portálok, modern backend-szolgáltatások, REST-API-k és integrációk tisztán csatlakozniuk kell a meglévő vállalati rendszerekhez.
C# megtekintése
Architektur
Layer-3 a monolitikus örökség helyett
Szándékosan elválasztjuk a felületet, az üzleti logikát és az adat-hozzáférést, hogy a változtatások tervezhetők maradjanak, és az új szolgáltatásokat ne kelljen a meglévő rendszer ellen építeni.
Layer-3 megtekintése
Plattformen
Windows 11 ARM64-t már a tervezésnél figyelembe venni
A hagyományos x64 célok mellett korán figyelembe vesszük az aktuális platformokat, például Windows 11 ARM64, hogy az új hardver és a telepítések később ne váljanak külön projekté.
ARM64 megtekintése
Mikor melyik irány érdemes
Delphi ésszerű, ha
- a meglévő szakmai logika továbbra is fennmaradjon,
- a komplex desktop-folyamatoknak stabilnak kell maradniuk,
- Windows-, macOS- és Linux-kliensek közös szakmai alapra épüljenek.
C# é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 é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 adatkészletet használják,
- a modernizációt fokozatosan, Layer-3-szerkezetként kell végrehajtani.
Delphi-modernizáció a gyakorlatban
Ha egy régi Delphi-alkalmazás szakmailag még értékes, nem vakon modernizálunk. Először elemezzük, hogyan működik a rendszer ténylegesen, mely folyamatokat támogatja, hol törnek meg az adatfolyamok és mely örökségek lassítják az üzemeltetést. Ebből egy modernizációs útvonal jön létre, amely nemcsak papíron tűnik tisztának, hanem a gyakorlatban is fenntartható marad.
Sok, évek óta kiforrott alkalmazás esetén az igazi érték nem a felületen, hanem az évek során felhalmozott üzleti logikában, egyedi szabályokban, kivételekben és tapasztalati tudásban rejlik. Ezt az értéket nem dobjuk el könnyelműen. Felelősségek tiszta szétválasztását végrehajtjuk, az adatbázist újrarendezzük, lecseréljük a régi hozzáférési útvonalakat, új REST-interfészeket hozunk létre, és szükség esetén ugyanazon szakmai alapokra épülő klienseket egészítünk ki Windows, macOS és Linux számára. Így nem keletkezik éles törés, hanem egy átlátható továbbfejlesztés jön létre, világos műszaki meghatározással.
Gyakran ez azt is jelenti, hogy a történelmileg kialakult monolitokat ismét olyan formába hozzuk, amely karbantartható, tesztelhető és bővíthető. Az adathozzáférés stabilizálódik, az üzleti logikát kivesszük a felületkódból, az interfészek tervezhetővé válnak, és a jövőbeli bővítéseket nem kell többé a meglévő rendszer ellenében kiküzdeni. A cél nem kozmetikai modernizáció, hanem egy olyan rendszer kialakítása, amely a vállalat számára ismét teret ad az új követelményekhez.
Szolgáltatások és szerverek ugyanazon architektúra részét képezik
Sok vállalati rendszernek ma már nemcsak kliensre van szüksége, hanem háttérszolgáltatásokra, Windows- vagy Linux-szolgáltatásokra és REST-szerverekre is. Éppen ezért ezeket a részeket nem utólagos toldásként tervezzük, hanem ugyanazon architektúra elemeiként. Egy olyan szolgáltatás, amely csak később valahogy hozzáadódik, szinte mindig különleges esetté válik.
Ha az adatok elosztva kerülnek feldolgozásra, interfészeket kell biztosítani, exportokat kell futtatni, importokat felügyelni vagy feladatokat időzítve háttérben végrehajtani, a műszaki felelősséget már a kezdetektől tisztázni kell. Mely részek futnak a kliensen, 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 egy terhelhető, átfogó rendszer jöhessen létre.
Ez különösen fontos multiplatform-projektek esetén. Egy asztali kliens Windows-en, macOS-on vagy Linux-on szakmailag nem jelenthet mást, mint egy 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 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 vallási elv. Döntő az, hogy az architektúra, a csapatképessé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 szabályozható.
Egyes feladatokat szándékosan Delphi segítségével oldunk meg, mert ott a felhalmozódott üzleti logika, a nagy teljesítményű kliensek és a multiplatform-képesség érvényesülnek. Más követelmények jobban illeszkednek C#-hez, szolgáltatásokhoz, egy portálhoz vagy ezek kombinációjához. A jó architektúra nem divatból születik, hanem világosságból: mely rendszer rész milyen felelősséget visel, milyen élettartam várható, mekkora a csapat, mennyire kritikus az üzemeltetés, és mely bővítések várhatóan reálisan felmerülnek a következő években?
Itt kezdődik számunkra a professzionális szoftverfejlesztés. Nem csupán olyasmit akarunk szállítani, ami ma működik, hanem egy olyan műszaki alapot létrehozni, amely később is átlátható, átvehető és gazdaságosan karbantartható.
Gyakran ismételt kérdések a technológiáról és az architektúráról
A technológiai döntéseknek a csapathoz, a szakmai követelményekhez és az üzemeltetéshez kell igazodniuk. Éppen ezért ezeket a kérdéseket nem elvontan tisztázzuk, hanem mindig az adott rendszeren.
Mikor indokolt Delphi egy teljesen új platform helyett?
Mindig akkor, amikor a felhalmozódott szakmai logikát, a nagy teljesítményű asztali folyamatokat és a multiplatform célokat gazdaságosan szeretnénk továbbvinni, ahelyett hogy a meglévő rendszerelemeket könnyelműen lecserélnénk.
Mikor érdemes kiegészítésként alkalmazni C#-t?
Különösen portálokhoz, web-backendekhez, REST-szolgáltatásokhoz, integrációkhoz és szolgáltatásorientált architektúrarészekhez, amelyek jól integrálhatók a meglévő asztali rendszerekkel.
Mennyire fontos a gyakorlatban Layer-3?
Nagyon. Csak a UI, az üzleti logika és az adatelérés tiszta szétválasztása teszi kezelhetővé a modernizálást, a tesztelést, a szolgáltatásokat és a későbbi platformváltásokat.
Számolnak-e már korán olyan új platformokkal, mint Windows 11 ARM64?
Igen. Az új célhardvert és a telepítési útvonalakat korán felmérjük, hogy később ne váljanak belőlük költséges különprojektek.
További kérdések egy helyen
Ezek a rövid válaszok itt maradnak az oldalon. A központi FAQ-landingoldalon további kontextusba helyezzük a témát az architektúra, a modernizálás, a platformok és az üzemeltetés vonatkozásában.