Thread View: pl.comp.lang.delphi
4 messages
4 total messages
Started by jh
Sat, 26 Nov 2016 23:13
API czy client-server u siebie?
Author: jh
Date: Sat, 26 Nov 2016 23:13
Date: Sat, 26 Nov 2016 23:13
36 lines
2753 bytes
2753 bytes
Rozpoczynam projekt, który w założeniach ma być otwarty na dodawanie third-party dodatków. Projekt składa się z kilku aplikacji pracujących docelowo na różnych stanowiskach/serwerach, komunikujących się ze sobą oraz serwerem bazodanowym. API - chyba warto pójść "z duchem czasów" i zamiast DLL czy COM umożliwić wymianę danych z systemem przez HTTP/HTTPS (+ REST/JSON). Rozważam, czy użyć do tego TMS Business Subscription, bo ma w zasadzie wszystko, co potrzeba. Przy czym projekt od strony bazodanowej trzeba by robić korzystając z ichniego ORMa (Aurelius), żeby to działało. No chyba, że ograniczyć koszt i skorzystać z INDY + to, co do JSONa jest już w Delphi. No i mam taki lekki dylemat, czy komunikację pomiędzy elementami systemu (moimi) zrobić w oparciu o to samo API, czy jednak skorzystać z z architektury client-server w oparciu o standardowe datasety (FireDAC). Niedawno byłem zmuszony zrobić aplikację, która pytała o dane przez SOAP i to, co wracało bywało duże, więc przez IIS z aplikacją SOAPową (taką architekturę miał klient), z którego brałem dane "przylatywały" jakieś 30-200 razy wolniej niż bezpośrednio z bazy (c-s), zależnie od rozmiaru danych. Ale nie wiem, czy to przypadłość IIS, aplikacji SOAP, czy generalnie przerobienia danych przez oba na XML, potem w Delphi wpisania tego do datasetu. Szacuję, że liczba klientów mojego systemu to średnio 5-50 jednoczesnych połączeń, choć większość czyta dane. Baza - MS SQL Server 2014, Express wystarczy. Co radzicie? Może jednak standardowe DLL do poszczególnych modułów? API ogólnie ma pozwolić na dodawanie/usuwanie/zmianę pojedynczych (umownie) "rekordów", oraz na przeglądanie - i tu mogą być zestawy zwracające nawet kilkanaście tysięcy rekordów (rzadko, ale jednak). Korzystam z Delphi Pro (Berlin 10.1). jh
Re: API czy client-server u siebie?
Author: Piotr Rezmer
Date: Mon, 28 Nov 2016 17:02
Date: Mon, 28 Nov 2016 17:02
16 lines
1464 bytes
1464 bytes
W dniu 2016-11-27 o 00:13, jh pisze: > Co radzicie? Może jednak standardowe DLL do poszczególnych modułów? API > ogólnie ma pozwolić na dodawanie/usuwanie/zmianę pojedynczych (umownie) > "rekordów", oraz na przeglądanie - i tu mogą być zestawy zwracające > nawet kilkanaście tysięcy rekordów (rzadko, ale jednak). Bardzo mało piszesz o tym jak aplikacja ma działać. Dlaczego potrzebujesz w niej elementów napisanych w Delphi? Nie lepiej będzie napisać w Javie z użyciem Spring Data? -- pozdrawiam Piotr XLR250&bmw_f650_dakar
Re: API czy client-server u siebie?
Author: jh
Date: Wed, 30 Nov 2016 08:01
Date: Wed, 30 Nov 2016 08:01
10 lines
2021 bytes
2021 bytes
W dniu poniedziałek, 28 listopada 2016 18:02:19 UTC+1 użytkownik Piotr Rezmer napisał: > Bardzo mało piszesz o tym jak aplikacja ma działać. Dlaczego > potrzebujesz w niej elementów napisanych w Delphi? Nie lepiej będzie > napisać w Javie z użyciem Spring Data? Cały system będzie z założenia desktopowy, działa w zasadzie tylko w LANie, baza MSSQL, komunikacja z urządzeniami w sieci lokalnej (TCP/UDP). Jednak do części funkcjonalności muszę pozostawić otwartość dla obcych rozwiązań. Ja z kolei korzystam z API dostarczonymi w postaci DLL oraz SOAP. jh
Re: API czy client-server u siebie?
Author: Piotr Rezmer
Date: Wed, 30 Nov 2016 15:37
Date: Wed, 30 Nov 2016 15:37
15 lines
1813 bytes
1813 bytes
W dniu 2016-11-30 o 09:01, jh pisze: > Cały system będzie z założenia desktopowy, działa w zasadzie tylko w LANie, baza MSSQL, komunikacja z urządzeniami w sieci lokalnej (TCP/UDP). Jednak do części funkcjonalności muszę pozostawić otwartość dla obcych rozwiązań. Ja z kolei korzystam z API dostarczonymi w postaci DLL oraz SOAP. Najfajniej byłoby wydzielić w systemie elementy generujące informacje i elementy konsumujące informacje. Generatory mogłyby wrzucać informacje na kolejki JMS a konsumenci nasłuchiwać na tych kolejkach i odpowiednio reagować (np. korzystać z REST lub SOAP) i zrealizować logikę biznesową. W ten sposób uzyskasz bardzo elastyczną architekturę do której będzie łatwo dodawać nowe elementy. -- pozdrawiam Piotr XLR250&bmw_f650_dakar
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads