Profil technologiczny
Przegląd naszej bazy technicznej
Delphi. C#. SQL. APIs.
Technologie, które pasują do logiki biznesowej, danych i operacji.
Technologia w obrazach
Decyzje technologiczne są u nas widoczne dzięki architekturze docelowej.
Decydujące nie jest samo hasło, lecz to, jak platforma, usługi i warstwy będą później współdziałać. Te szkice czynią obrany kierunek uchwytnym.
Wspólny rdzeń dla wielu celów
Wieloplatformowość ma sens, gdy wielu klientów korzysta z tej samej logiki domenowej i nie dochodzi do ich rozbieżności.
* Użyte nazwy platform i znaki towarowe należą do ich odpowiednich właścicieli.
C# i usługi jako uzupełnienie
Portale, REST i usługi uzupełniają rdzeń tam, gdzie logika webowa i operacyjna staje się bardziej zaawansowana.
Wczesne uwzględnienie sprzętu docelowego
Przejścia na platformy, takie jak ARM64, należą do zakresu architektury i wdrożeń, zanim staną się problemem wsparcia technicznego.
Odpowiednie ścieżki usług i technologii
Ważne pogłębienia dotyczące tego tematu
Technologii nie stosujemy według mody, lecz zgodnie z realiami operacyjnymi, żywotnością, potrzebą integracji i zdolnością zespołu. Kluczowe nie jest słowo-klucz, lecz to, czy system później będzie możliwy do czystej eksploatacji, rozszerzania i przejęcia.
Silny w logice biznesowej i klientach wieloplatformowych
Delphi sprawdza się tam, gdzie rozbudowana logika biznesowa, procesy bliskie bazie danych, raporty i stabilne aplikacje klienckie dla Windows, macOS i Linux mają być utrzymane długoterminowo.
Zobacz Delphi
C#
Odpowiedni dla REST, usług i portali
C# stosujemy, gdy portale, nowoczesne usługi backendowe, API REST i integracje mają być w uporządkowany sposób podłączone do istniejących systemów przedsiębiorstwa.
Zobacz C#
Architektur
Layer-3 statt monolithischer Altlast
Świadomie oddzielamy warstwę prezentacji, logikę biznesową i dostęp do danych, aby zmiany pozostały planowalne i nowe serwisy nie musiały być budowane kosztem istniejącego systemu.
Zobacz Layer-3
Plattformen
Uwzględniać Windows 11 ARM64 od razu
Obok klasycznych celów x64 uwzględniamy wcześnie aktualne platformy takie jak Windows 11 ARM64, aby nowy sprzęt i wdrożenia nie stały się później odrębnym projektem.
Zobacz ARM64
Kiedy która ścieżka jest wskazana
Delphi ist sinnvoll, wenn
- istniejąca logika fachowa ma być dalej utrzymana,
- złożone procesy desktopowe muszą pozostać stabilne,
- aplikacje klienckie dla Windows, macOS i Linux mają powstać na wspólnej bazie merytorycznej.
C# ist sinnvoll, wenn
- tworzone są serwery REST i usługi,
- API i integracje zewnętrzne znajdują się w centrum,
- wymagane są nowoczesne architektury usług.
Hybrid ist sinnvoll, wenn
- istniejące aplikacje i nowe portale muszą ze sobą współpracować,
- aplikacje desktopowe, usługi i aplikacje webowe korzystają z tej samej bazy danych,
- modernizacja ma przebiegać etapami i w formie struktury Layer-3.
Delphi-modernizacja w praktyce
Jeśli stara aplikacja Delphi nadal ma wartość merytoryczną, nie modernizujemy na ślepo. Najpierw analizujemy, jak system rzeczywiście działa, jakie procesy obsługuje, gdzie przepływy danych się załamują i które obciążenia historyczne spowalniają eksploatację. Na tej podstawie powstaje ścieżka modernizacji, która nie tylko dobrze wygląda na papierze, lecz w codziennym użytkowaniu pozostaje wykonalna.
W wielu rozwijających się aplikacjach rzeczywista wartość nie leży w interfejsie, lecz w latach logiki domenowej, reguł specjalnych, wyjątków i wiedzy praktycznej. Tej substancji nie wyrzuca się lekkomyślnie. Rozdzielamy odpowiedzialności w sposób klarowny, porządkujemy bazę danych, zastępujemy stare ścieżki dostępu, tworzymy nowe REST-interfejsy i w razie potrzeby uzupełniamy klientów dla Windows, macOS i Linux na tej samej podstawie merytorycznej. W ten sposób nie powstaje gwałtowny przeskok, lecz dająca się prześledzić ewolucja o jasnym technicznym ukierunkowaniu.
Często oznacza to także przywrócenie historycznie ukształtowanych monolitów do postaci, która jest utrzymywalna, testowalna i rozszerzalna. Dostęp do danych zostaje ustabilizowany, logika biznesowa wydzielona z kodu warstwy prezentacji, interfejsy stają się planowalne, a przyszłe rozszerzenia nie muszą być już wywalczane przeciwko istniejącemu systemowi. Celem nie jest kosmetyczna modernizacja, lecz system, który znów daje firmie przestrzeń na nowe wymagania.
Usługi i serwery jako część tej samej architektury
Wiele systemów przedsiębiorstw wymaga dziś nie tylko klienta, lecz także usług działających w tle, usług Windows lub Linux oraz serwerów REST. Właśnie dlatego planujemy te elementy nie jako późniejszy przyrost, lecz jako część tej samej architektury. Usługa, która dołącza dopiero później w jakiś sposób, niemal zawsze staje się przypadkiem szczególnym.
Jeśli dane mają być przetwarzane rozproszenie, udostępniane interfejsy, wykonywane eksporty, monitorowane importy lub zadania uruchamiane cyklicznie w tle, odpowiedzialność techniczna musi być wyjaśniona od początku. Które części działają w kliencie, które w usłudze, które na serwerze, jak będą widoczne błędy, jak będą śledzone zmiany stanu, jak zachować spójność logiki domenowej? Na te pytania odpowiadamy wcześnie, aby z pojedynczych elementów powstał solidny system całościowy.
To jest szczególnie istotne przy projektach multiplatformowych. Desktopowy klient na Windows, macOS lub Linux nie może merytorycznie znaczyć czegoś innego niż towarzyszący serwer REST lub usługa działająca w tle. Dlatego myślimy o modelu danych, procesach, uprawnieniach, integracjach i eksploatacji zawsze łącznie. Powstaje w ten sposób architektura, w której klienci, usługi i serwery mówią tym samym językiem.
Nasz fundament
Technologia nie jest dla nas systemem wierzeń. Decydujące jest, aby architektura, zdolność zespołu, eksploatacja i przyszłe rozszerzenia pasowały do firmy. Nie wygrywa najgłośniejsza platforma, lecz ta, za pomocą której ryzyko, utrzymywalność i wzrost da się sensownie kontrolować.
Niektóre zadania rozwiązujemy świadomie za pomocą Delphi, ponieważ tam ukształtowana logika biznesowa, wydajne klienty i zdolność multiplatformowa pokazują swoje atuty. Inne wymagania lepiej pasują do C#, do usług, do portalu lub do kombinacji obu. Dobra architektura nie rodzi się z mody, lecz z klarowności: jaka odpowiedzialność przypada której części systemu, jaka przewidywana jest żywotność, jak duży jest zespół, jak krytyczna jest eksploatacja i jakie rozszerzenia realistycznie nadejdą w najbliższych latach?
Właśnie tam zaczyna się dla nas profesjonalne tworzenie oprogramowania. Nie chcemy jedynie dostarczyć czegoś, co działa dziś, lecz zbudować techniczną podstawę, która także później będzie zrozumiała, możliwa do przejęcia i ekonomicznie utrzymywalna.
Często zadawane pytania dotyczące technologii i architektury
Decyzje technologiczne muszą pasować do zespołu, do wymagań merytorycznych i do eksploatacji. Właśnie dlatego nie rozstrzygamy tych kwestii abstrakcyjnie, lecz zawsze na przykładzie konkretnego systemu.
Kiedy Delphi ma sens w porównaniu z całkowicie nową platformą?
Za każdym razem, gdy rozwinięta logika fachowa, wydajne procesy desktopowe i cele multiplatformowe mają być kontynuowane w sposób ekonomiczny, zamiast lekkomyślnie wymieniać rdzeń systemu.
Kiedy dodatkowo stosują Państwo C#?
Przede wszystkim dla portali, web-backendów, REST-usługi, integracji oraz komponentów architektury zorientowanej na usługi, które można dobrze zintegrować z istniejącymi systemami desktopowymi.
Jak ważny jest Layer-3 w praktyce?
Bardzo. Dopiero czyste rozdzielenie UI, logiki biznesowej i dostępu do danych sprawia, że modernizacja, testy, usługi i przyszłe zmiany platform są opanowalne.
Czy uwzględniają Państwo nowe platformy, takie jak Windows 11 ARM64, już we wczesnej fazie?
Tak. Nowy sprzęt docelowy i ścieżki wdrożeniowe są sprawdzane wcześnie, aby później nie przerodziły się w kosztowne projekty specjalne.
Zobacz pozostałe zebrane pytania
Te krótkie odpowiedzi pozostają na tej stronie. Na centralnej stronie FAQ przedstawiamy ten temat dodatkowo w kontekście architektury, modernizacji, platform i eksploatacji.
Następny krok
Jeśli mają Państwo konkretną kwestię dotyczącą modernizacji, API lub platformy, powinniśmy na wczesnym etapie jednoznacznie i precyzyjnie określić zakres techniczny.
Net-Base ocenia istniejące systemy, ścieżki danych, interfejsy i platformy docelowe nie w izolacji, lecz w kontekście logiki domenowej, eksploatacji i późniejszej rozbudowy.
- Stan istniejący, obraz docelowy i ryzyka techniczne są oceniane łącznie.
- REST, dostęp do danych, portale i Rollout nie są odkładane na później.
- Wcześnie widzą Państwo, która droga jest ekonomicznie opłacalna i operacyjnie wykonalna.