Kérdések és válaszok
Központi GYIK áttekintése
Ki felel a vállalatnál az adatvédelemért?
A felelősség a vállalatvezetésnél marad. Feladatok delegálhatók, de a döntésekért, a prioritásokért és a megfelelő szolgáltatók bevonásáért viselt felelősség nem.
Mikor indokolt adatvédelmi tisztviselő?
Ez a feldolgozások jellegétől és terjedelmétől, a jogszabályi kötelezettségektől és a belső szervezettség szintjétől függ. Ott is, ahol nincs formális kötelezettség, hasznos lehet a külső támogatás ahhoz, hogy az adatvédelem strukturáltan be legyen ágyazva.
Milyen terjedelműnek kell lennie egy ISO-9001-dokumentációnak?
Olyan terjedelműnek, amilyen szükséges, de a lehető legkarcsúbbnak. A dokumentációnak a folyamatokat, szerepeket és bizonyítékokat kell leképeznie, nem pedig szövegekkel túlterhelnie a szervezetet.
Mit ad egy belső audit, ha még nem minden tökéletes?
Éppen ilyenkor értékes egy belső audit. Megmutatja, hol még pontatlanok a szabályok, a bizonyítékok vagy a felelősségi körök, és mely intézkedések fejtik ki először a hatásukat.
Mit vizsgálnak konkrétan egy internetes audit során?
Tipikusan a tracking- és cookie-logikát, az űrlapokat, a hírlevélfolyamatokat, a külső szolgáltatásokat, a hostingot, a frissítések karbantartását, a szerepköröket, az átirányításokat, a biztonsági alapokat, valamint ezek adatvédelmi jogi besorolását.
Az adatvédelem csak jogi téma?
Nem. Az adatvédelemnek mindig vannak szervezeti és technikai oldalai is. Tiszta folyamatok és technikai értelmezés nélkül a jogi előírások a mindennapokban nehezen ültethetők át.
Milyen gyorsan alakítható ki egy terhelhető állapot?
Ez a meglévő állapottól függ. Többnyire egy első, strukturált munkaszint jóval gyorsabban elérhető, mint egy teljes végleges változat. A döntő az, hogy a témákat ésszerűen priorizáljuk.
Hogyan kapcsolódik egymáshoz az adatvédelem, a QM és a weboldal-üzemeltetés?
Ugyanazt az alapvető kérdést osztják: mely folyamatokat hogyan irányítják, dokumentálják, ellenőrzik és fejlesztik? Pontosan ezért sok témát célszerűbb együtt, mint elszigetelten kezelni.
Adathozzáférés
BDE-kiváltás
A BDE ritkán csak egy régi driver. Többnyire történeti SQL-logikához, adatbázis-feltételezésekhez és deployment-útvonalakhoz kapcsolódik. Pont ezért itt tudatosan valamivel tágabban válaszoljuk meg a témát.
A BDE ritkán csak egyetlen technikai építőelem. SQL-hez, deploymenthez, driverekhez, karakterkészletekhez és történetileg kialakult mellékhatásokhoz kötődik. Ezért a kiváltást modernizációs lépésként kezeljük, nem pedig komponenscseréként.
Lehetséges a váltás FireDAC-re vagy natív driverekre teljes átépítés nélkül?
Igen, gyakran lépésekben. Fontos az SQL, az adattípusok, a tranzakciók és a speciális esetek tiszta ellenőrzése, ahelyett hogy csak 1:1-ben cserélnénk komponenseket.
Miért érinti a BDE-kiváltás szinte mindig az adatbázisstruktúrát is?
Mert ilyenkor gyakran láthatóvá válnak régi táblák, indexek, karakterkészletek és történetileg kinőtt SQL-útvonalak, amelyeket a stabilitás és a teljesítmény érdekében érdemes vele együtt rendbe tenni.
Mit nyerünk konkrétan a natív adatbázis-kapcsolattal?
Egyszerűbb deploymentet, jobb karbantarthatóságot, kontrollálható kapcsolatokat és lényegesen jobb alapot szolgáltatásokhoz, API-khoz és jövőbeli bővítésekhez.
A téma részletesen
Ha ebből a FAQ-ból a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
C#
C# szolgáltatásokhoz & portálokhoz
Ez a GYIK azoknak a vállalatoknak szól, akik a C#-et nem öncélként, hanem portálok, API-k, integrációk és szolgáltatásorientált architektúraelemek erős építőköveként szeretnék értelmezni.
Számunkra a C# elsősorban akkor erős, ha a webportálok, API-k, szolgáltatások, integrációk és egy nyugodt, üzemeltetésre hangolt kialakítás áll a fókuszban.
Mikor jobb választás a C# a Delphi-hez képest?
Elsősorban akkor, ha egy projekt elsődlegesen REST-API-kból, portálokból, backend-szolgáltatásokból, integrációkból vagy felhőközeli üzemeltetési modellekből áll.
Használják a C#-et meglévő Delphi-rendszerekkel együtt is?
Igen. Pont ez a kombináció gyakran célszerű: a Delphi viszi az éles üzleti logikát a kliensben, miközben a C# tisztán kiegészíti a szolgáltatásokat, portálokat és az API-rétegeket.
Mik a tipikus kockázatok C#-projektekben?
Gyakran túl gyorsan épül technikailag modern megoldás, anélkül hogy a szerepeket, a szakterületi logikát, a naplózást, a telepítést és a valós üzemeltetési kérdéseket kellően korán, tisztán lehatárolnák. Mi pontosan itt avatkozunk be.
Téma részletesebb kifejtése
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggéseket architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
C# szolgáltatásokhoz és portálokhoz – részletek megtekintése
Delphi-csapat
Delphi-fejlesztők Freiburgból
Ennél a megkeresésnél ritkán van szó csupán egy elérhető személyről. Többnyire az a kérdés áll mögötte, hogy egy partner valóban teherbíró módon át tudja-e venni az örökséget, a szakterületi logikát, az adatelérést és a technikai irányt.
Delphi-fejlesztők keresésénél ritkán csak szabad kapacitásról van szó. Többnyire a meglévő rendszer, az architektúra, az adatelérés és a valódi szakmai felelősség teherbíró átvételéről.
Mikor indokolt egy külsős Delphi-fejlesztő?
Elsősorban akkor, ha hiányzik a meglévő tudás, a modernizáció elakadt, vagy egy alkalmazást szakmailag tovább kell fejleszteni úgy, hogy közben ne veszítse el a lényegét.
Be tudnak kapcsolódni kinőtt, öröklött Delphi-alkalmazásokba is?
Igen. Pont ez az egyik fókusz: elemezzük a régi kódot, az adatbázist, a telepítést, a különleges eseteket és a szakmai folyamatokat, és erre építve, kontrolláltan fejlesztünk tovább.
Csak programozásról van szó, vagy a technikai irányról is?
Kifejezetten az irányról is. Számunkra a jó Delphi-fejlesztés magában foglalja az architektúrát, az adatelérést, az integrációkat, a REST-szolgáltatásokat és a valós üzemeltetést.
Téma részletesebb kifejtése
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggéseket architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Modernizáció
Delphi-modernizáció
Ezek a válaszok elsősorban ott segítenek, ahol egy örökölt alkalmazás szakmailag még erős, technikailag azonban túl sok fékezőpontot gyűjtött össze ahhoz, hogy az új követelményeket tisztán elbírja.
A modernizáció kritikus pontja ritkán csak a felület. Többnyire a szakmai logikáról, az adatokról, a függőségekről és egy olyan migrációs stratégiáról szól, amely a napi üzemmenetben is működik.
Egy régi Delphi-alkalmazást teljesen le kell cserélni?
Nem. Gyakran egy kontrollált átépítés ésszerűbb: az adatelérést megújítani, a logikát szétválasztani, szolgáltatásokat kiegészíteni, és a felületeket célzottan modernizálni.
Hogyan kerülhető el az üzemmenet megszakadása a modernizáció során?
Világos köztes lépcsőkkel, tiszta interfészekkel és olyan migrációs úttal, amelyben a régi és az új részek kontrolláltan egymás mellett tudnak működni.
A meglévő szakmai logika később átvihető szolgáltatásokba vagy portálokba is?
Igen. Pontosan ezért emeljük ki az üzleti logikát az UI-közeli örökölt kódból, és olyan struktúrába visszük, amelyet a kliensek, a szolgáltatások és az API-k közösen tudnak használni.
Téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggéseket architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Technológia
Delphi multiplatform
Ez a GYIK a multiplatform-stratégia technikai oldalát tekinti át: kódbázis, csomagolás, rendszerközelség, kiadási folyamatok, valamint azt a kérdést, hogy mikor válik több kliens valóban gazdaságossá.
A multiplatform csak akkor működik tisztán, ha a kódbázist, az adatmodellt, a platformkülönbségeket és a deploymentet tudatosan megtervezik. Itt keletkezik a projekt tényleges értéke.
Valóban futhat ugyanaz az alkalmazás Windows, macOS és Linux alatt?
Igen, ha a felületet, a szakmai logikát, a platform sajátosságait és a kiadási folyamatokat nem keverik össze, hanem tisztán strukturálják.
Mi a leggyakoribb hiba multiplatform projektekben?
Túl későn gondolni a fájlrendszerre, a nyomtatásra, az aláírásra, a célplatformokra, a csomagolásra és az UI-különbségekre. Ilyenkor a multiplatform gyorsan drága és inkonzisztens lesz.
A szolgáltatások és az API-k használhatják ugyanazt a szakmai logikát?
Igen. Egy jó architektúra biztosítja, hogy ne minden platform alakítson ki saját szakmai különutat.
Téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggéseket architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Aki PostgreSQL-t és BDE-Ablösung mit nativer Anbindung-et használ, többnyire nem csak egy új komponenst akar. Mögötte gyakran az a kérdés áll, hogyan lehet az adatelérést, az SQL-t, a deploymentet és a meglévő logikát ismét egy teherbíró vonalba rendezni.
A PostgreSQL és a BDE-Ablösung mit nativer Anbindung esetében nem pusztán egy új kapcsolódási komponensről van szó. Többnyire egy nagyobb lépés áll mögötte a robusztusabb SQL, a jobb deployment és a kontrollálható adatkezelés felé.
Mikor jó választás a PostgreSQL a(z) Delphi számára?
Mindig akkor, amikor a stabilitás, a többfelhasználós működés, az egyértelmű SQL-útvonalak, a nyílt infrastruktúra és a tiszta bővíthetőség fontos desktop, szolgáltatások vagy portálok esetén.
A FireDAC mindig a helyes út?
A FireDAC gyakran nagyon jó út, de nem vak csere. A döntő tényezők az SQL-viselkedés, az adattípusok, a tranzakciók, a hibautak és a konkrét meglévő állomány.
A BDE-, Paradox- vagy régi SQL-rendszerek lépésenként át tudnak térni PostgreSQL-re?
Igen. Sok esetben egy kontrollált, lépcsőzetes átállási út gazdaságosabb, mint egy kemény váltás, amennyiben az adatmodellt és a szakterületi logikát is tisztán bevonják a tervezésbe.
Téma részletesebben
Ha erről a GYIK-ről a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a nagyobb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Delphi REST
Delphi REST-API & REST-szerver
Ez a GYIK megválaszolja azt a tipikus alapvető kérdést, hogy a(z) REST a(z) Delphi-vel csak egy technikai kiegészítés-e, vagy egy komoly szerverstratégia. Mindig az a döntő, mennyire tisztán tartják össze a klienst, a szabályokat, az adatokat és az üzemeltetést.
A REST a Delphi-vel akkor válik erőssé, ha az API-k nem leválasztva, a meglévő rendszer mellett állnak, hanem a jogosultságokat, az üzleti logikát, az adatmodellt és az üzemeltetést is tisztán viszik.
Lehet a(z) Delphi-vel éles REST-API-kat építeni?
Igen. Különösen akkor, ha ugyanaz a szakterületi logika már a(z) Delphi meglévő rendszerében él, egy tisztán vágott REST-szerver gyakran gazdaságosabb, mint egy teljesen új párhuzamos világ.
Mikor éri meg egy REST-szerver a közvetlen adatbázis-hozzáféréssel szemben?
Amint több kliens, portál, szolgáltatás vagy integráció kontrolláltan ugyanazokat a szabályokat kell, hogy használja, és a közvetlen SQL-hozzáférés szakmailag túl kockázatossá válik.
Hogyan tartja konzisztensen a Delphi-klienst és a REST-t?
Egy olyan architektúrával, ahol az üzleti szabályok nem maradnak űrlapokban elrejtve, hanem kliens, API és háttérfolyamatok számára közösen használhatóvá válnak.
Téma részletesebben
Ha erről a GYIK-ről a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a nagyobb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Delphi
Delphi vállalati alkalmazásokhoz
Itt arról az alapvető kérdésről van szó, hogy mikor tudatos architektúradöntés ma is a Delphi, és mikor érdemes más építőelemekkel érdemben kiegészíteni vagy átvenni a szerepét.
A Delphi esetében vállalati környezetben ritkán nosztalgiáról van szó, hanem arról a kérdésről, hogyan lehet a kialakult szakterületi logikát, a desktop folyamatokat és a több célplatformot gazdaságosan, tiszta módon továbbvinni.
Miért támaszkodik ma is tudatosan a(z) Delphi-re?
Mert a(z) Delphi sok vállalati alkalmazásban erős kombinációt ad: kiforrott üzleti logika, nagy teljesítményű desktop folyamatok, adatbázis-közelség és kontrollálható továbbfejlesztés.
A(z) Delphi csak a meglévő rendszerek modernizálásához érdekes?
Nem. A(z) Delphi új vállalati alkalmazásokhoz is ésszerű választás, ha fontosak a produktív desktop munkafolyamatok, a riportok, a helyi integráció, valamint a több platformon közös szakmai alap.
Hol vannak a(z) Delphi korlátai?
Elsősorban ott, ahol egy kezdeményezés alapvetően portál-, service- vagy felhőközpontú. Ilyenkor a(z) Delphi-t tudatosan kombináljuk a(z) C#-vel, REST-szerverekkel vagy webes építőelemekkel, ahelyett hogy mindent egyetlen eszközbe kényszerítenénk.
A téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggéseket architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Támogatás
Delphi karbantartás & támogatás
A karbantartás gyakran kisebbnek hangzik, mint amekkora valójában. A gyakorlatban stabil release-ekről, látható kockázatokról, műszaki rendre tételről és arról szól, hogyan lehet egy kinőtt rendszert ismét nyugodtan továbbfejleszteni.
A karbantartás a kinőtt Delphi-rendszereknél több, mint hibajavítás. Kiterjed a release-biztonságra, az adatok konzisztenciájára, a műszaki adósságra és arra a kérdésre, hogyan illeszthetők az új igények nyugodtan a meglévő állományba.
Mi tartozik egy jó Delphi karbantartáshoz?
Hibaanalízis, továbbfejlesztés, adatbázis-karbantartás, release-támogatás, műszaki dokumentáció és olyan architektúra, amely nem teszi minden alkalommal drágábbá az új igényeket.
El lehet indítani a támogatást teljes átalakítás nélkül is?
Igen. Gyakran stabilizálással, a kockázatok láthatóvá tételével, valamint a műszaki és szakmai fejlesztések priorizált listájával kezdődik.
Hogyan csökkentik az egyedi tudástól való függést?
Úgy, hogy az adatútvonalakat, komponenseket, build-lépéseket és kritikus szakmai logikát strukturáltan dokumentáljuk, és az implicit tudásból ismét követhető rendszerlogikát készítünk.
A téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggéseket architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Architektúra
Layer-3-architektúra
A Layer-3-t gyakran elméletben magyarázzák. A gyakorlatban azonban ez a struktúra nagyon közvetlenül dönti el, hogy az új kliensek, service-ek, tesztek és bővítések nyugodtan csatlakoznak-e, vagy drágán szétcsúsznak.
A Layer-3 nem tankönyvi szó, hanem nagyon praktikus válasz a kinőtt monolitokra, az egymásnak ellentmondó bővítésekre és a mindennapokban drága csatolásokra.
Miért olyan fontos a Layer-3 a vállalati alkalmazásoknál?
Mert csak a UI, az üzleti logika és az adatelérés tiszta szétválasztása biztosítja, hogy a bővítések, tesztek, szolgáltatások és az új platformok ne akadjanak el közvetlenül a monolitnál.
Csak nagy projektek esetén van értelme a Layer-3-nek?
Nem. Különösen a közepes méretű rendszerek profitálnak belőle erősen, mert így a későbbi igények lényegesen kontrolláltabban kapcsolhatók be.
Mi a leggyakoribb hiba a Layer-3 esetén?
Az, hogy a rétegeket csak formálisan rajzolják meg, a tényleges szabályokat viszont továbbra is az UI-kódban vagy közvetlenül SQL-speciális útvonalakban rejtik el. Ilyenkor a felépítés csak a fóliákon létezik, a rendszerben nem.
Téma részletesen
Ha ebből a GYIK-ből át szeretne váltani a mélyebb szakmai oldalra, ott megtalálja a tágabb összefüggést az architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Szolgáltatások
Szolgáltatások áttekintése
A szolgáltatási oldal kapcsán szoktak felmerülni a legszélesebb körű visszakérdezések: mit vállalunk konkrétan, meddig terjed a technikai felelősségünk, és hogyan illeszkedik egymásba a modernizáció, az integrációk, az üzemeltetés és a továbbfejlesztés?
Különösen a hosszú ideje fejlődő alkalmazásoknál gyakran ugyanazok a szakmai és technikai kérdések merülnek fel. Ezeket a pontokat korán tisztázzuk, mielőtt egy kezdeményezésből diffúz nagyprojekt lesz.
Átvesznek meglévő Delphi-rendszereket is?
Igen. Rendszeresen belépünk hosszú ideje fejlődő Delphi-alkalmazásokba, elemezzük az állományt, az adatelérést, az architektúrát és a speciális eseteket, és erre építve kontrolláltan fejlesztünk tovább.
Egyetlen kezdeményezésből származhatnak REST-szerverek, portálok és desktop kliensek?
Igen. Különösen vállalati alkalmazásoknál ezeket az építőelemeket tudatosan együtt tervezzük, hogy ugyanaz az üzleti logika ne több, egymástól eltérő egyedi megoldásban szakadjon szét.
Lehetséges a BDE kiváltása teljes csere nélkül is?
Sok esetben igen. Az adatelérést, az SQL-t és a deploymentet lépésről lépésre leválasztjuk a régi struktúráról, és natív, jól karbantartható kapcsolódást építünk ki.
Az üzemeltetést és a továbbfejlesztést is kísérik?
Igen. A release-folyamatok, a hosting, a hibaanalízis, az adatbázis-karbantartás és a későbbi bővítések a munkaképünk részei.
Téma részletesen
Ha ebből a GYIK-ből át szeretne váltani a mélyebb szakmai oldalra, ott megtalálja a tágabb összefüggést az architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Szolgáltatás
Multiplatform a Delphi-vel
A cégek ezen a ponton többnyire nem csak egy technikai lehetőségről kérdeznek, hanem egy terhelhető stratégiáról: mely részek maradnak közösek, mit kell platformspecifikusan kezelni, és hogyan lesz ebből nem drága párhuzamos fejlesztés?
A multiplatform akkor válik értékessé, ha ugyanaz a szakmai logika több célrendszeren át kontrolláltan együtt marad, és a platform sajátosságai korán láthatóvá válnak.
Lehet-e a Delphi mellett a Windows-on túl a macOS, a Linux, az iOS és az Android is eleve a tervezés része?
Igen. A projektcéltól függően a desktop célokat, a mobil felületeket és a szerverközeli komponenseket egy közös szakmai vonal mentén tervezzük meg, ahelyett hogy minden platformot szakmailag elölről építenénk fel.
Hogyan kerülik el, hogy a multiplatform projektek szakmailag szétcsússzanak?
Közös kód- és architektúrastratégiával: az üzleti szabályok, az adatmodell és a folyamatok központiak maradnak, miközben a platformspecifikus különbségek tudatosan kapszulázva vannak.
Később is lehetségesek még mobil bővítési lépcsők?
Igen. Ha az architektúra, a szolgáltatások és az interfészek tisztán elő vannak készítve, az iOS- vagy Android-célok később lényegesen kontrolláltabban illeszthetők.
Téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Projektek
Projektképek és referenciaminták
Aki a projektoldalra néz, általában azt szeretné megérteni, milyen jellegű kezdeményezéseket viszünk ténylegesen: egyszeri eszközöket, vagy hosszabb életű rendszereket üzemeltetéssel, jogosultsági koncepcióval, verziókkal, integrációkkal és valódi továbbfejlesztéssel.
Sok kezdeményezés kezdetben különbözőnek hangzik, mégis közös mintáik vannak: kialakult üzleti logika, integrációk, jogosultságok, verziók, üzemeltetési kérdések és hosszú távú bővíthetőség.
Inkább egyszeri egyedi eszközökön dolgoznak, vagy hosszabb távon fenntartható rendszereken?
A fókusz olyan rendszereken van, amelyeknél futamidő, felelősség és továbbfejlesztés van: vállalati alkalmazások, platformok, szolgáltatások, portálok és terméklogika.
Modernizálhatók párhuzamosan meglévő termékek vagy belső rendszerek?
Igen. Különösen a hosszabb ideje növekedett rendszereknél gyakran lépcsőzetes továbbfejlesztést tervezünk, hogy az üzemeltetés és a modernizáció összehangolt legyen.
A hosting és a technikai üzemeltetés is a munkájuk része?
Igen. A release, a hosting, a monitoring és az üzemeltetési felelősség beépül a projekttervezésünkbe, hogy a kész megoldás ne csak le legyen fejlesztve, hanem fenntarthatóan üzemeltethető is legyen.
Téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Szerverarchitektúra
REST-szerver & szolgáltatások
Ha az API-k és szolgáltatások csak technikailag hangzanak korszerűnek, de szakmailag nincsenek tisztán szétvágva, gyorsan problémává válnak. Ez a GYIK pontosan ezeket a döntéseket rendezi keretbe.
Sok rendszer nem az API-ötleten bukik el, hanem azon, hogy a szerverlogikát később improvizatívan csatolják hozzá egy meglévő desktop állományhoz. Mi ezeket a részeket tudatosan együtt tervezzük.
Mikor van egy vállalati alkalmazásnak a REST-szerverre is szüksége?
Amint több kliens, portál, mobil hozzáférés, külső integráció vagy leválasztott folyamat ellenőrzött módon ugyanazt a szakterületi logikát kell, hogy használja.
Támogatnak Windows- és Linux-szolgáltatásokat is?
Igen. Háttérfolyamatok, időzítés, szinkronizáció, exportok, licencszolgáltatások és technikai kísérőfolyamatok a tipikus feladataink közé tartoznak.
Hogyan marad meg a szakterületi konzisztencia a kliens, a REST és a szolgáltatás között?
Olyan architektúrával, ahol az üzleti szabályok nincsenek elrejtve egyes felületekben, hanem közösen használhatók és követhetőek maradnak.
Téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Szolgáltatás
Szolgáltatások, REST-Server & portálok
Különösen itt kell együtt maradnia a jogosultságoknak, az adatáramlásoknak, a naplózásnak és a szakterületi szabályoknak. Ezért nem webes toldalékként kezeljük a témát, hanem ugyanazon alkalmazási vonal rendezett bővítéseként.
A portálok, REST-API-k és szolgáltatások csak akkor működnek jól, ha szakterületileg nem a kernrendszer mellett állnak, hanem ugyanazt az adat- és szerepkörlogikát tisztán viszik tovább.
Fejlesztenek REST-Servert, valamint Windows- és Linux-szolgáltatásokat is?
Igen. Háttérszolgáltatások, API-k, importok, exportok, portálok és technikai üzemeltetési logika a visszatérő feladatképeink közé tartoznak.
Mikor van szüksége egy vállalati alkalmazásnak portálra is?
Mindig akkor, amikor ügyfelek, partnerek vagy belső szerepkörök ellenőrzötten ugyanazokhoz a folyamatokhoz kell, hogy hozzáférjenek, anélkül hogy a szakterületi szabályokat külön felületekben duplikálnánk.
Hogyan maradnak konzisztensen a jogosultságok, a naplózás és a folyamatok a kliens és a szerver között?
Úgy, hogy nem rejtjük el a szakterületi szabályokat egyes végpontokban vagy UI-kban, hanem létrehozunk egy világos szakmai középpontot, amelyet a kliens, a portál és a szolgáltatás közösen használhat.
Téma részletesen
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Szolgáltatások, REST-Server & portálok részletes megtekintése
Technológiák
Technológia és architektúra áttekintése
Ez a GYIK összefogja a technológiai döntéshez tartozó tipikus tájékozódó kérdéseket: mikor erős a Delphi, mikor a C# a jobb építőelem, és hogyan fog össze egy tiszta architektúra több platformot, szolgáltatást és klienst ellenőrzötten?
A technológiai döntéseknek illeszkedniük kell a csapathoz, a szakterülethez és az üzemeltetéshez. Pontosan ezért ezeket a kérdéseket nem absztraktan tisztázzuk, hanem mindig a konkrét rendszeren.
Mikor ésszerű a Delphi egy teljes újraplatformolással szemben?
Mindig akkor, amikor a kinőtt szakmai 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ő alapokat könnyelműen lecserélnénk.
Mikor vet be kiegészítőként a(z) C#-t?
Elsősorban portálokhoz, webes back-endekhez, REST-szolgáltatásokhoz, integrációkhoz és szolgáltatásorientált architektúra-elemekhez, amelyek jól illeszthetők a meglévő desktop rendszerekhez.
Mennyire fontos a(z) Layer-3 a gyakorlatban?
Nagyon. Csak az UI, az üzleti logika és az adat-hozzáférés tiszta szétválasztása teszi kezelhetővé a modernizációt, a teszteket, a szolgáltatásokat és a jövőbeli platformváltásokat.
Korán számolnak olyan új platformokkal is, mint a(z) Windows 11 ARM64?
Igen. Az új célhardvert és a telepítési/deployment útvonalakat korán megvizsgáljuk, hogy később ne váljanak belőlük költséges különprojektek.
A téma részletes olvasása
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a nagyobb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Vállalati szoftver
Egyedi vállalati szoftver és Layer-3
Ezek a kérdések tipikusan akkor merülnek fel, amikor a standard szoftver szakmailag már nem elég, és egy vállalat tudni szeretné, hogy egy egyedi rendszer valóban gazdaságosan, karbantarthatóan és bővíthetően megépíthető-e.
Különösen az egyedi vállalati szoftvereknél nem csupán egyes felületekről van szó, hanem szerepkörökről, adatokról, ellenőrzési útvonalakról és olyan architektúráról, amely később is rugalmas marad.
Az egyedi vállalati szoftver csak nagyon nagy vállalatoknak éri meg?
Nem. Mindig akkor térül meg, amikor a standard szoftver csak kerülőutakkal, médiumtörésekkel vagy drága egyedi szabályokkal tud folyamatokat leképezni, és a tényleges érték a tiszta szakmai logikában van.
Miért hangsúlyozzák ennyire a(z) Layer-3-t a vállalati alkalmazásoknál?
Mert csak az UI, az üzleti logika és az adat-hozzáférés szétválasztása biztosítja, hogy a riporting, az új kliensek, a szolgáltatások és a jövőbeli bővítések gazdaságilag kontrollálhatók maradjanak.
Be tudnak kapcsolódni kinőtt, meglévő folyamatokba is?
Igen. Különösen akkor lesz erős a munkánk, amikor a szakmai folyamatokat, a meglévő adatokat és a régi logikát először olvashatóvá tesszük, és ebből egy teherbíró célarchitektúrát dolgozunk ki.
A téma részletes olvasása
Ha ebből a GYIK-ből a mélyebb szakmai oldalra szeretne továbblépni, ott megtalálja a nagyobb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Egyedi vállalati szoftver és Layer-3-alkalmazások részletes megtekintése
Platform
Windows 11 ARM64
Az ARM64 sok alkalmazást a vártnál korábban érint. Ez a GYIK a függőségekkel, tesztekkel, telepítőkkel és az új célhardverek gazdasági besorolásával kapcsolatos tipikus kérdésekre ad választ.
Az ARM64 ma már nem egzotikus mellékszál, hanem valós célplatform. Aki korán számol vele, elkerüli a későbbi technikai zsákutcákat a deploymentben és a natív függőségek körül.
Miért érdemes Windows 11 ARM64-t már ma figyelembe venni?
Mert az új hardverosztályok és a mobil munkahelyek egyre inkább erre építenek, és a későbbi technikai utómunka lényegesen drágább, mint egy korai architektúradöntés.
Mi különösen kritikus Delphi és natív függőségek esetén ARM64-en?
Mindenekelőtt a külső könyvtárakat, adatbázis-illesztőket, installereket, setup-folyamatokat és a valódi célhardveren végzett teszteket kell korán ellenőrizni.
Szükséges ARM64-hez egy teljesen külön terméket létrehozni?
Nem feltétlenül. Gyakran elég a build- és deployment-útvonalakat tisztán előkészíteni, és a kritikus natív függőségeket időben szétválasztani.
A téma részletesen
Ha ebből a GYIK-ből átvált a mélyebb szakmai oldalra, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.
Szolgáltatások
Windows- és Linux-szolgáltatások
A szolgáltatásoknál ritkán csak egy futó folyamatról van szó. Fontosabb a naplózás, a megfigyelhetőség, az újraindítás, az adatok konzisztenciája és az a szakmai kérdés, mely részeknek kell a háttérben futniuk, és melyeknek nem.
A háttérszolgáltatások gyakran egy rendszer láthatatlan magját adják. Nyugodtan kell futniuk, tisztán kell kezelniük az állapotváltásokat, és a naplózással, újraindítással és monitoringgal robusztusan kell illeszkedniük az üzemeltetésbe.
Mikor van szüksége egy vállalati alkalmazásnak kiegészítő Windows- vagy Linux-szolgáltatásokra?
Mindig akkor, amikor importok, exportok, időzítés, szinkronizáció, licenc-logika vagy integrációk nem lehetnek egy bejelentkezett asztali környezethez kötve.
Származhatnak a szolgáltatások és a REST ugyanabból az architektúrából?
Igen. Ez gyakran kifejezetten ésszerű, mert így a business logika, az adatmodell és a naplózás nem esik szét több technikai szigetre.
Mi különösen fontos éles szolgáltatásoknál?
Egyértelmű hibakezelés, megfigyelhető állapotok, újraindítás-biztonság, naplózás, deployment, és egy szakmailag konzisztens feldolgozás a csendes háttérmágia helyett.
A téma részletesen
Ha ebből a GYIK-ből átvált a mélyebb szakmai oldalra, ott megtalálja a tágabb összefüggést architektúrával, példákkal, döntési indokokkal és kapcsolódó témákkal.