Přehled
FAQ v přehledu
FAQ landingpage
Klíčové otázky a odpovědi k zahájení projektu, službám, podnikovému softwaru, Delphi, architektuře, portálům, službám a modernizaci.
Tato stránka shromažďuje nejčastější otázky z naší úvodní stránky, přehledových stránek a odborných podstránek na jednom místě. Kompaktní FAQ záměrně zůstávají i na příslušných detailních stránkách. Zde je navíc řadíme jako landingpage, aby zájemci rychle viděli, která témata skutečně ovládáme v oblasti zahájení projektu, služeb, Delphi, C#, Layer-3, portálů, modernizace, přístupu k datům a platformní strategie.
Můžete buď rovnou přejít na tematický blok, nebo níže vždy přejít na prohlubující podstránku. Stránka tak zůstává použitelná jak jako rychlý vstup, tak jako strukturovaný FAQ hub.
Zahájení projektu
Zahájení projektu, architektura & spolupráce
Otázky k smysluplnému vstupu, k inventuře stávajícího stavu a k raným architektonickým rozhodnutím.
Přímo k odpovědím
Služby
Přehled služeb
Otázky k převzetí stávajícího systému, modernizaci, službám, přístupu k datům a dlouhodobé péči.
Přímo k odpovědím
Technologie
Přehled technologií a architektury
Dotazy k Delphi, C#, Layer-3, volbě platformy a technickému směru napříč několika rozvojovými etapami.
Přejít přímo na odpovědi
Projekty
Obrázky projektů a referenční vzory
Dotazy k velikosti projektu, provozní odpovědnosti, hostingu, produktové logice a systémům s delší životností.
Přejít přímo na odpovědi
Podnikový software
Individuální podnikový software & Layer-3
Dotazy k ekonomice, procesní logice, rolím, datům a dlouhodobé rozšiřitelnosti.
Přejít přímo na odpovědi
Výkon
Multiplatformně s Delphi
Dotazy k Windows, macOS, Linux a také k pozdějším cestám pro iOS a Android ze společné doménové logiky.
Přejít přímo na odpovědi
Výkon
Služby, REST-Server & portály
Dotazy k portálům, API, službám Windows a Linux jako součásti téže doménové architektury.
Přejít přímo na odpovědi
Integrace
Rozhraní, datové toky & cílové platformy
Dotazy k finančnímu účetnictví, API, přestavbě databáze, mapování, monitoringu a novým cílovým platformám.
Přejít přímo na odpovědi
Delphi
Delphi pro podnikové aplikace
Proč může být Delphi stále silné u vyrostlé business logiky, reportů a produktivních desktopových procesů.
Přejít přímo na odpovědi
C#
C# pro služby & portály
Dotazy k REST, integracím, portálům, backendovým službám a klidnému provozu.
Přejít přímo na odpovědi
Architektura
Architektura Layer-3
Dotazy k oddělení UI, business logiky a datového přístupu a proč je to ekonomicky přímo relevantní.
Přejít přímo na odpovědi
Tým Delphi
Vývojáři Delphi z Freiburgu
Dotazy k externí podpoře, převzetí stávajícího řešení a technické odpovědnosti ve vyrostlých systémech Delphi.
Přejít přímo k odpovědím
Provozní podpora
Delphi-údržba & provozní podpora
Dotazy ke stabilizaci, dalšímu vývoji, bezpečnosti releasů a omezení závislosti na znalostech jednotlivců.
Přejít přímo k odpovědím
Modernizace
Modernizace Delphi
Dotazy k modernizačnímu postupu, riziku, zachování doménové logiky a postupné obnově za běžného provozu.
Přejít přímo k odpovědím
Přístup k datům
Náhrada BDE
Dotazy k FireDAC, nativním ovladačům, specifikům SQL, deploymentu a nové organizaci databáze.
Přejít přímo k odpovědím
PostgreSQL
Delphi, PostgreSQL & FireDAC
Dotazy k migraci na PostgreSQL, nativním ovladačům, chování SQL a klidné přestavbě datového přístupu.
Přejít přímo k odpovědím
Delphi REST
Delphi REST-API & REST-server
Dotazy k REST s Delphi, vymezení API, sdílené doménové logice a čisté serverové architektuře.
Přejít přímo k odpovědím
Služby
Windows- & Linux-služby
Dotazy k background službám, časovému řízení, monitoringu, chování při restartu a čistému vymezení pro provoz.
Přejít přímo k odpovědím
Technologie
Delphi multiplatformně
Dotazy ke společné kódové bázi pro Windows, macOS a Linux s kontrolovanými hranicemi platforem.
Přejít přímo k odpovědím
Serverová architektura
REST-server & služby
Dotazy k API, službám pro Windows a Linux, serverové logice, monitoringu a provozní odpovědnosti.
Přejít přímo k odpovědím
Platforma
Windows 11 ARM64
Dotazy k novému hardwaru, nativním závislostem, ovladačům, buildům a rolloutovým postupům.
Přejít přímo k odpovědím
Zahájení projektu
Zahájení projektu, architektura & spolupráce
Mnoho prvních otázek se netočí kolem jedné konkrétní technologie, ale kolem správného výchozího bodu: Co je potřeba nejdřív vyjasnit, jak vzniká technická orientace a jak se z nápadu stane robustní vstup do reálného projektu?
Na úvodní stránce se obvykle objevují první orientační otázky: Jak začít záměr smysluplně, které architektonické otázky je vhodné řešit brzy a kdy se vyplatí modernizace místo hektického nového vývoje?
Kdy se vyplatí modernizace Delphi místo kompletního nového vývoje?
Pokud jsou doménová logika, procesy a datový model hodnotné, je řízená přestavba často ekonomičtější než nový začátek se ztrátou funkcí a vysokým rizikem při zavádění.
Může stejná doménová logika běžet pro Windows, macOS a Linux?
Ano. Zejména u projektů Delphi navrhujeme společnou business logiku a oddělujeme uživatelské rozhraní, služby a přístup k datům tak, aby bylo možné čistě obsloužit více platforem.
Vyvíjí Net-Base také servery REST a služby na pozadí?
Ano. Služby Windows a Linux, API REST, integrační vrstvy a deployment jsou pro nás součástí architektury a nepřidávají se až dodatečně.
Jak začíná typický projekt?
Většinou strukturovaným zmapováním stavu: cíle, existující systémy, databáze, platformy, rozhraní a provozní rizika. Z toho vznikne realisticky vymezitelný výchozí bod.
Přečíst téma podrobněji
Pokud chcete z tohoto FAQ přejít na odbornější stránku, najdete tam širší kontext včetně architektury, příkladů, rozhodovacích důvodů a navazujících témat.
Služby
Přehled služeb
Na stránce služeb obvykle vznikají nejširší doplňující otázky: Co konkrétně přebíráme, kam sahá naše technická odpovědnost a jak do sebe zapadají modernizace, integrace, provoz a další rozvoj?
Zejména u dlouhodobě vyvíjených aplikací se často objevují stejné doménové i technické otázky. Tyto body vyjasňujeme brzy, ještě než se ze záměru stane nejasný rozsáhlý projekt.
Přebíráte také existující systémy Delphi?
Ano. Pravidelně vstupujeme do vyrostlých aplikací Delphi, analyzujeme stávající stav, přístup k datům, architekturu a speciální případy a na tom kontrolovaně navazujeme.
Mohou v rámci jednoho záměru vzniknout servery REST, portály i desktopoví klienti?
Ano. Zejména u podnikových aplikací tyto stavební bloky záměrně plánujeme společně, aby se stejná business logika nerozpadla do několika izolovaných speciálních řešení.
Je možné nahradit BDE i bez kompletní výměny?
V mnoha případech ano. Přístup k datům, SQL a deployment postupně vyvazujeme ze staré struktury a budujeme nativní, udržovatelné napojení.
Doprovázíte také provoz a další rozvoj?
Ano. Release procesy, hosting, analýza chyb, údržba databáze a pozdější rozšíření jsou součástí naší práce.
Přečíst téma podrobněji
Pokud chcete z tohoto FAQ přejít na odbornou stránku do větší hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Technologie
Přehled technologie a architektury
Toto FAQ sdružuje typické orientační otázky k technologickému rozhodování: Kdy je Delphi silné, kdy je C# lepší stavební prvek a jak čistá architektura kontrolovaně propojí více platforem, služeb a klientů?
Technologická rozhodnutí musí odpovídat týmu, doméně i provozu. Právě proto tyto otázky nevyjasňujeme abstraktně, ale vždy na konkrétním systému.
Kdy má Delphi smysl oproti kompletní nové platformě?
Vždy tehdy, když se má ekonomicky udržet vyrostlá doménová logika, výkonné desktopové procesy a cíle pro více platforem, namísto lehkovážné náhrady hodnotné substance.
Kdy navíc používáte C#?
Především pro portály, webové backendy, REST-služby, integrace a části servisně orientované architektury, které se dobře provazují se stávajícími desktopovými systémy.
Jak důležité je Layer-3 v praxi?
Velmi. Teprve čisté oddělení UI, business logiky a přístupu k datům dělá modernizaci, testování, služby i budoucí změny platforem zvládnutelnými.
Zvažujete nové platformy jako Windows 11 ARM64 už včas?
Ano. Nový cílový hardware a cesty nasazení se prověřují brzy, aby se z toho později nestaly nákladné speciální projekty.
Přečíst téma v detailu
Pokud chcete z tohoto FAQ přejít na odbornou stránku do větší hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Projekty
Ukázky projektů a referenční vzory
Kdo se dívá na stránku projektů, většinou chce pochopit, jaký typ záměrů skutečně uneseme: jednorázové nástroje, nebo déle žijící systémy s provozem, konceptem oprávnění, verzemi, integracemi a skutečným dalším vývojem.
Mnoho záměrů zní na začátku odlišně, a přesto mají společné vzory: vyrostlou doménovou logiku, integrace, oprávnění, verze, provozní otázky a dlouhodobou rozšiřitelnost.
Pracujete spíše na jednorázových jednotlivých nástrojích, nebo na systémech s delší životností?
Těžiště je na systémech s běžným provozem, odpovědností a dalším vývojem: podnikové aplikace, platformy, služby, portály a produktová logika.
Lze modernizovat stávající produkty nebo interní systémy paralelně?
Ano. Právě u systémů, které dlouho rostly, často plánujeme etapový další vývoj, aby provoz a modernizace dávaly dohromady smysl.
Je hosting a technický provoz součástí vaší práce?
Ano. Release, hosting, monitoring a provozní odpovědnost jsou součástí našeho projektového plánování, aby hotové řešení nebylo jen vyvinuto, ale také udržitelně provozováno.
Téma si přečtěte podrobně
Pokud chcete z tohoto FAQ přejít na odbornou stránku do větší hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Podnikový software
Individuální podnikový software & Layer-3
Tyto otázky se typicky objevují ve chvíli, kdy standardní software už odborně nestačí a firma potřebuje vědět, zda lze individuální systém postavit skutečně ekonomicky, udržitelně a rozšiřitelně.
Právě u individuálního podnikového softwaru nejde jen o jednotlivé obrazovky, ale o role, data, kontrolní stopy a architekturu, která zůstane flexibilní i později.
Dává individuální podnikový software smysl jen pro velmi velké firmy?
Ne. Vyplatí se vždy, když standardní software mapuje procesy jen oklikami, s přerušováním mezi systémy nebo s drahými speciálními pravidly – a skutečná hodnota je v čisté odborné logice.
Proč u podnikových aplikací tak silně zdůrazňujete Layer-3?
Protože teprve oddělení UI, business logiky a přístupu k datům zajišťuje, že reporting, nové klienty, služby a budoucí rozšíření zůstanou ekonomicky pod kontrolou.
Dokážete se zapojit i do vyrostlých stávajících procesů?
Ano. Právě tehdy je naše práce silná, protože nejdřív zpřehledníme odborné procesy, existující data a starou logiku a z toho vyvineme nosnou cílovou architekturu.
Téma si přečtěte podrobně
Pokud chcete z tohoto FAQ přejít na odbornou stránku do větší hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Zobrazit individuální podnikový software & aplikace Layer-3 podrobně
Výkon
Multiplatformní vývoj s Delphi
Firmy se v tomto bodě obvykle neptají jen na technickou možnost, ale na odolnou strategii: které části zůstanou společné, co je nutné řešit platformně specificky a jak z toho nevznikne drahá paralelní výstavba?
Multiplatformní přístup má hodnotu teprve tehdy, když stejná odborná logika zůstává napříč více cílovými systémy řízeně společná a specifika platforem se zviditelní včas.
Lze s Delphi kromě Windows zohlednit také macOS, Linux, iOS a Android?
Ano. Podle cíle projektu plánujeme desktopové cíle, mobilní rozhraní i serverově blízké komponenty z jedné společné odborné linie, místo aby se každá platforma odborně stavěla znovu.
Jak zabráníte tomu, aby se multiplatformní projekty odborně rozcházely?
Společnou strategií pro kód a architekturu: odborná pravidla, datový model a procesy zůstávají centrální, zatímco platformně specifické rozdíly jsou vědomě zapouzdřené.
Jsou pozdější mobilní rozšiřující stupně stále možné?
Ano. Pokud jsou architektura, služby a rozhraní čistě připravené, lze cíle pro iOS nebo Android později připojit výrazně kontrolovaněji.
Přečíst téma podrobně
Pokud chcete z této FAQ přejít na podrobnější odbornou stránku, najdete tam širší souvislosti včetně architektury, příkladů, důvodů pro rozhodnutí a navazujících témat.
Služba
Services, REST-Servery & portály
Právě zde musí zůstat pohromadě oprávnění, datové toky, logging a odborná pravidla. Proto téma neřešíme jako webový přívěsek, ale jako řízené rozšíření téže aplikační linie.
Portály, REST-API a služby se dobře prosazují jen tehdy, pokud odborně nestojí vedle core systému, ale čistě přenášejí stejnou datovou a rolovou logiku.
Vyvíjíte jak REST-servery, tak i Windows- a Linux-services?
Ano. Služby na pozadí, API, importy, exporty, portály a technická provozní logika patří k našim opakovaným typům úloh.
Kdy podniková aplikace navíc potřebuje portál?
Vždy tehdy, když mají zákazníci, partneři nebo interní role řízeně přistupovat ke stejným procesům, aniž by bylo nutné duplikovat odborná pravidla v oddělených rozhraních.
Jak zůstanou oprávnění, logging a procesy mezi klientem a serverem konzistentní?
Tím, že odborná pravidla neschováváme do jednotlivých endpointů nebo UI, ale vytvoříme jasný odborný střed, který mohou společně využívat klient, portál i služba.
Přečíst téma podrobně
Pokud chcete z této FAQ přejít na podrobnější odbornou stránku, najdete tam širší souvislosti včetně architektury, příkladů, důvodů pro rozhodnutí a navazujících témat.
Integrace
Rozhraní, datové toky & cílové platformy
Tyto otázky přicházejí většinou ve chvíli, kdy se kvalita dat, dohledatelnost a budoucí změny platformy stanou důležitějšími než samotný přenos dat z A do B.
Rozhraní často působí jako vedlejší téma. Ve skutečnosti rozhodují o kvalitě dat, dohledatelnosti, změnách platformy a klidném provozu.
Lze stávající rozhraní a datové toky obnovit bez Big Bangu?
Ano. V mnoha projektech postupně nově uspořádáme mapping, databázové cesty, joby a integrace tak, aby reálné procesy mohly běžet dál.
Přebíráte také napojení na finanční účetnictví a systémy třetích stran?
Ano. Právě Fibu, API, CRM, sklad, licenční logika nebo oborově specifické systémy třetích stran musí být napojeny čistě, zdokumentovaně, pozorovatelně a odborně kontrolovatelně.
Zohledňujete v takových integračních projektech rovnou i cílové platformy jako Windows 11 ARM64?
Ano. Nové cílové platformy, nativní závislosti a budoucí způsoby deploymentu patří včas do stejného plánování jako rozhraní a logika datových toků.
Přečíst téma podrobně
Pokud chcete z této FAQ přejít na podrobnější odbornou stránku, najdete tam širší kontext s architekturou, příklady, důvody rozhodnutí a souvisejícími tématy.
Delphi
Delphi pro podnikové aplikace
Jde zde o zásadní otázku, kdy je Delphi i dnes vědomým architektonickým rozhodnutím a kdy by jiné stavební bloky měly smysluplně doplňovat nebo převzít část řešení.
U Delphi jde ve firmách zřídka o nostalgii, ale o otázku, jak ekonomicky a architektonicky čistě dál provozovat vyrostlou doménovou logiku, desktopové procesy a více cílových platforem.
Proč dnes stále vědomě sázíte na Delphi?
Protože Delphi v mnoha podnikových aplikacích nabízí silnou kombinaci vyrostlé business logiky, výkonných desktopových procesů, blízkosti databázi a kontrolovatelného dalšího vývoje.
Je Delphi zajímavý jen pro modernizaci stávajících systémů?
Ne. Delphi dává smysl i pro nové podnikové aplikace, pokud jsou důležité produktivní desktopové postupy, reporty, lokální integrace a společný doménový základ pro více platforem.
Kde jsou hranice Delphi?
Především tam, kde je záměr primárně portálový, servisní nebo cloudově centric. Pak Delphi vědomě kombinujeme s C#, REST servery nebo webovými komponentami, místo abychom všechno tlačili do jednoho nástroje.
Přečíst téma detailně
Pokud chcete z této FAQ přejít na podrobnější odbornou stránku, najdete tam širší kontext s architekturou, příklady, důvody rozhodnutí a souvisejícími tématy.
C#
C# pro služby & portály
Tato FAQ je určena firmám, které chtějí C# chápat ne jako samoúčel, ale jako silný stavební blok pro portály, API, integrace a části servisně orientované architektury.
C# je pro nás silný zejména tehdy, když jsou v popředí webové portály, API, služby, integrace a klidně navržený provozní střih.
Kdy je C# oproti Delphi lepší volba?
Především tehdy, když se projekt primárně skládá z REST API, portálů, backendových služeb, integrací nebo provozních modelů blízkých cloudu.
Využíváte C# také společně se stávajícími systémy Delphi?
Ano. Právě tato kombinace je často smysluplná: Delphi nese produktivní doménovou logiku v klientovi, zatímco C# čistě doplňuje služby, portály a vrstvy API.
Jaká jsou typická rizika u projektů C#?
Často se příliš rychle staví technicky moderně, aniž by se role, doménová logika, logging, deployment a reálné provozní otázky dostatečně brzy čistě vymezily. Přesně tam navazujeme.
Přečíst téma detailně
Pokud chcete z této FAQ přejít na podrobnější odbornou stránku, najdete tam širší kontext s architekturou, příklady, důvody rozhodnutí a souvisejícími tématy.
Architektura
Layer-3-architektura
Layer-3 se často vysvětluje teoreticky. V praxi však tato struktura velmi přímo rozhoduje o tom, zda se nové klienty, služby, testy a rozšíření napojují klidně, nebo se draze rozbíhají.
Layer-3 není učebnicové slovo, ale velmi praktická odpověď na narostlé monolity, rozporná rozšíření a nákladná provázání v každodenním provozu.
Proč je Layer-3 u podnikových aplikací tak důležitá?
Protože teprve čisté oddělení UI, business logiky a datového přístupu zajistí, že rozšíření, testy, služby a nové platformy neselžou přímo na monolitu.
Má Layer-3 smysl jen pro velké projekty?
Ne. Zejména středně velké systémy z toho výrazně těží, protože se tím dají pozdější požadavky napojovat podstatně kontrolovaněji.
Jaká je nejčastější chyba u Layer-3?
Že se vrstvy kreslí jen formálně, ale skutečná pravidla se dál schovávají v UI kódu nebo přímo ve speciálních SQL cestách. Pak existuje struktura jen na slidech, ne v systému.
Číst téma podrobně
Pokud chcete z této FAQ přejít na odbornou stránku do větší hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Delphi-tým
Delphi-vývojáři z Freiburgu
U této poptávky jde jen zřídka pouze o dostupnou osobu. Většinou za tím stojí otázka, zda partner dokáže skutečně spolehlivě převzít stávající systém, doménovou logiku, datový přístup a technický směr.
Při hledání Delphi-vývojářů jde jen zřídka pouze o volnou kapacitu. Většinou jde o spolehlivé převzetí stávajícího systému, architektury, datového přístupu a skutečné odborné odpovědnosti.
Kdy dává externí Delphi-vývojář smysl?
Především tehdy, když chybí znalost stávajícího řešení, modernizace se zasekla nebo je potřeba aplikaci doménově dále rozvíjet, aniž by ztratila svou podstatu.
Můžete se zapojit i do narostlých Delphi-aplikací?
Ano. Přesně to je jedno z hlavních zaměření: analyzujeme starý kód, databázi, deployment, speciální případy a doménové procesy a na tom kontrolovaně stavíme dál.
Jde jen o programování, nebo i o technický směr?
Jde výslovně i o směr. Dobrá Delphi-vývojová práce pro nás zahrnuje architekturu, datový přístup, integrace, REST-služby a reálný provoz.
Číst téma podrobně
Pokud chcete z této FAQ přejít na odbornou stránku do větší hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Podpora
Delphi-údržba & podpora
Údržba často zní menší, než ve skutečnosti je. V praxi jde o stabilní releasy, viditelná rizika, technický pořádek a otázku, jak lze vyrostlý systém znovu klidně dál rozvíjet.
Údržba je u vyrostlých systémů Delphi víc než jen opravy chyb. Týká se bezpečnosti release, konzistence dat, technického dluhu a otázky, jak nové požadavky klidně zapadnou do stávajícího řešení.
Co patří k dobré údržbě Delphi?
Analýza chyb, další rozvoj, péče o databázi, doprovod release, technická dokumentace a architektura, která nové požadavky neprodražuje pokaždé.
Může podpora začít i bez kompletní přestavby?
Ano. Často začíná stabilizací, zviditelněním rizik a prioritizovaným seznamem technických i odborných zlepšení.
Jak snižujete závislost na individuálním know-how?
Tím, že strukturovaně dokumentujeme datové cesty, komponenty, build kroky a kritickou doménovou logiku a z implicitních znalostí znovu děláme dohledatelnou systémovou logiku.
Přečíst téma podrobně
Pokud chcete z této FAQ přejít na odbornou stránku do hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Modernizace
Modernizace Delphi
Tyto odpovědi pomáhají hlavně tam, kde je starší aplikace po odborné stránce stále silná, technicky ale nasbírala příliš mnoho brzdných míst, aby dokázala nové požadavky čistě unést.
Kritický bod modernizace je zřídka jen uživatelské rozhraní. Většinou jde o doménovou logiku, data, závislosti a migrační strategii, která funguje v každodenním provozu.
Musí být stará aplikace Delphi kompletně nahrazena?
Ne. Často je smysluplnější kontrolovaná přestavba: obnovit přístup k datům, oddělit logiku, doplnit služby a cíleně modernizovat rozhraní.
Jak se při modernizaci vyhnout narušení provozu?
Díky jasným mezikrokům, čistým rozhraním a migrační cestě, ve které mohou staré i nové části kontrolovaně existovat vedle sebe.
Může stávající doménová logika později přejít i do služeb nebo portálů?
Ano. Právě proto uvolňujeme business logiku z legacy kódu těsně svázaného s UI a přenášíme ji do struktury, kterou mohou společně využívat klienti, služby a API.
Přečíst téma podrobně
Pokud chcete z této FAQ přejít na odbornou stránku do hloubky, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Přístup k datům
Náhrada BDE
BDE je zřídka jen starý ovladač. Většinou je navázaná na historickou SQL logiku, předpoklady o databázi a deploymentové postupy. Právě proto zde téma záměrně pokrýváme trochu šířeji.
BDE je jen zřídka pouze jeden technický stavební prvek. Váže se na SQL, deployment, ovladače, znakové sady a historické vedlejší efekty. Proto vnímáme náhradu jako krok modernizace, nikoli jako pouhou výměnu komponenty.
Je přechod na FireDAC nebo nativní ovladače možný bez kompletní přestavby?
Ano, často po etapách. Důležité je pečlivě prověřit SQL, datové typy, transakce a speciální případy, místo aby se komponenty jen 1:1 nahradily.
Proč se náhrada BDE téměř vždy týká i databázové struktury?
Protože se při ní často zviditelní staré tabulky, indexy, znakové sady a historicky vyvinuté SQL cesty, které by se kvůli stabilitě a výkonu měly zároveň upravit.
Co konkrétně přináší nativní databázové napojení?
Jednodušší deployment, lepší udržovatelnost, lépe kontrolovatelná spojení a výrazně lepší základ pro služby, API a budoucí rozšíření.
Přečíst téma do hloubky
Pokud chcete z této FAQ přejít na odbornější stránku, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Kdo používá PostgreSQL a BDE-Ablösung mit nativer Anbindung, obvykle chce víc než jen novou komponentu. Často za tím stojí otázka, jak vrátit datový přístup, SQL, deployment a stávající logiku do udržitelné linie.
U PostgreSQL a BDE-Ablösung mit nativer Anbindung nejde jen o novou komponentu připojení. Ve většině případů je za tím větší krok směrem k robustnějšímu SQL, lepšímu deploymentu a lépe kontrolovatelnému nakládání s daty.
Kdy je PostgreSQL pro Delphi dobrou volbou?
Vždy tehdy, když jsou důležité stabilita, víceuživatelský provoz, jasné SQL cesty, otevřená infrastruktura a čistá rozšiřitelnost pro desktop, služby nebo portály.
Je FireDAC vždy správná cesta?
FireDAC je často velmi dobrá cesta, ale ne jako bezmyšlenkovitá výměna. Rozhodující jsou chování SQL, datové typy, transakce, chybové cesty a konkrétní stávající stav.
Mohou BDE-, Paradox- nebo staré SQL systémy přecházet na PostgreSQL postupně?
Ano. V mnoha případech je řízený postup po etapách ekonomičtější než tvrdý řez, pokud se čistě promyslí datový model i doménová logika.
Přečíst téma do hloubky
Pokud chcete z této FAQ přejít na odbornější stránku, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Delphi REST
Delphi REST API & REST server
Tato FAQ odpovídá na typickou zásadní otázku, zda je REST s Delphi jen technický doplněk, nebo seriózní serverová strategie. Rozhodující je vždy to, jak čistě se drží pohromadě klient, pravidla, data a provoz.
REST s Delphi je silné tehdy, když API nestojí odděleně vedle stávajícího systému, ale konzistentně nese oprávnění, business logiku, datový model i provoz.
Lze s Delphi vytvářet produktivní REST API?
Ano. Zejména když stejná doménová logika už žije ve stávajícím Delphi systému, je čistě vyřezaný REST server často ekonomičtější než úplně nový paralelní svět.
Kdy se vyplatí REST server oproti přímému přístupu do databáze?
Jakmile má více klientů, portálů, služeb nebo integrací kontrolovaně používat stejná pravidla a přímý SQL přístup se z hlediska domény stává příliš rizikovým.
Jak udržujete Delphi klienta a REST konzistentní?
Architekturou, ve které business pravidla nezůstávají skrytá ve formulářích, ale stanou se společně použitelnými pro klienta, API i background procesy.
Číst téma detailně
Pokud chcete z tohoto FAQ přejít na hlubší odbornou stránku, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Služby
Windows- & Linux-Services
U služeb jde málokdy jen o běžící proces. Důležitější jsou logging, observabilita, opětovné spuštění, datová konzistence a doménová otázka, které části patří na pozadí a které ne.
Background služby jsou často neviditelným jádrem systému. Musí běžet klidně, čistě zpracovávat změny stavů a zapadnout robustně do provozu pomocí logování, restartů a monitoringu.
Kdy potřebuje podniková aplikace navíc Windows- nebo Linux-Services?
Vždy, když importy, exporty, časové plánování, synchronizace, licenční logika nebo integrace nemají být vázány na přihlášený desktop.
Mohou služby a REST vycházet ze stejné architektury?
Ano. Právě to je často smysluplné, protože se tím business logika, datový model a logging nerozbíhají do několika technických ostrovů.
Co je pro produktivní služby obzvlášť důležité?
Jasné ošetření chyb, pozorovatelné stavy, restart bezpečnost, logging, deployment a doménově konzistentní zpracování místo tiché magie na pozadí.
Číst téma detailně
Pokud chcete z tohoto FAQ přejít na hlubší odbornou stránku, najdete tam širší souvislosti s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Technologie
Delphi Multiplatform
Toto FAQ osvětluje technickou stránku multiplatformní strategie: codebase, packaging, blízkost k systému, release procesy a otázku, kdy se více klientů skutečně vyplatí.
Multiplatforma funguje čistě jen tehdy, když jsou codebase, datový model, rozdíly platforem a deployment vědomě naplánovány. Právě tam vzniká skutečná projektová hodnota.
Může stejná aplikace opravdu běžet na Windows, macOS a Linux?
Ano, pokud se nebudou míchat UI, doménová logika, specifika platforem a release procesy, ale budou čistě strukturované.
Jaká je nejčastější chyba u multiplatformních projektů?
Přemýšlet příliš pozdě o souborovém systému, tisku, podepisování, cílových platformách, balíčkování a rozdílech v UI. Pak se multiplatformní vývoj rychle prodraží a bude nekonzistentní.
Mohou služby a API využívat stejnou doménovou logiku?
Ano. Dobrá architektura zajistí, aby si každá platforma nevyvinula vlastní doménovou odbočku.
Přečíst téma podrobně
Pokud z tohoto FAQ chcete přejít na odbornější stránku, najdete tam širší kontext včetně architektury, příkladů, důvodů rozhodnutí a navazujících témat.
Serverová architektura
REST server & služby
Když API a služby znějí technicky moderně, ale nejsou doménově čistě vymezené, rychle se stanou problémem. Toto FAQ tyto volby přesně zasazuje do kontextu.
Mnoho systémů neselže na myšlence API, ale na tom, že se serverová logika později improvizovaně připojí k existující desktopové aplikaci. Tyto části vědomě plánujeme společně.
Kdy potřebuje podniková aplikace navíc REST server?
Jakmile má více klientů, portálů, mobilních přístupů, externích integrací nebo oddělených procesů kontrolovaně využívat stejnou doménovou logiku.
Podporujete také Windows a Linux služby?
Ano. Background procesy, plánování úloh, synchronizace, exporty, licenční služby a technické doprovodné procesy patří k našim typickým úkolům.
Jak se zachová doménová konzistence mezi klientem, REST a službou?
Pomocí architektury, ve které nejsou business pravidla schovaná v jednotlivých UI, ale zůstávají společně použitelná a dohledatelná.
Přečíst téma podrobně
Pokud z tohoto FAQ chcete přejít na odbornější stránku, najdete tam širší kontext včetně architektury, příkladů, důvodů rozhodnutí a navazujících témat.
Platforma
Windows 11 ARM64
ARM64 se u mnoha aplikací projeví dříve, než se čeká. Toto FAQ odpovídá na typické otázky kolem závislostí, testů, instalátorů a ekonomického zařazení nového cílového hardwaru.
ARM64 už není exotické vedlejší téma, ale reálná cílová platforma. Kdo s ní počítá včas, vyhne se pozdějším technickým slepým uličkám v deploymentu a u nativních závislostí.
Proč by se Windows 11 ARM64 mělo zohlednit už dnes?
Protože na něj stále více sází nové třídy hardwaru a mobilní pracovní místa a pozdější technické dodělávky budou výrazně dražší než včasné architektonické rozhodnutí.
Co je u Delphi a nativních závislostí na ARM64 obzvlášť kritické?
Především externí knihovny, databázové ovladače, instalátory, instalační procesy a testy na skutečném cílovém hardwaru je nutné ověřit včas.
Musí pro ARM64 vzniknout úplně samostatný produkt?
Ne nutně. Často stačí čistě připravit buildové a deploymentové cesty a včas oddělit kritické nativní závislosti.
Přečíst téma podrobně
Pokud chcete z této FAQ přejít na podrobnější odbornou stránku, najdete tam širší souvislost s architekturou, příklady, důvody rozhodnutí a navazujícími tématy.
Má se z FAQ stát konkrétní projektová konzultace?
Pak dalším smysluplným krokem není další sbírka hesel, ale strukturované zařazení vašeho stávajícího řešení: Jaká odborná logika je přítomná, kde brzdí současná architektura, která rozhraní jsou kritická a jaká rozšiřující cesta je technicky skutečně udržitelná?