[Parseval]

Cześć,

Zrobiłem prosty system IoT bazujący na MQTT i JSONach. Serwer odbiera wiadomość, robi dispatch i przekazuje żądanie do konkretnego interfejsu, który parsuje requesta, składa odpowiedź i publikuje na MQTT. Kolekcjonowanie danych do złożenia odpowiedzi naturalnie odbywa się na różne sposoby (komunikacja po fizycznych interfejsach z czujnikami) w zależności co jest żądane. Jednak czuję, że architektonicznie mogłoby coś zagrać lepiej jeśli chodzi o budowanie odpowiedzi.
Chodzi mi po głowie stworzenie jakiegoś generycznego buildera, ale każdy pomysł finalnie kończy się wnioskiem o braku korzyści z takiego rozwiązania, bo jest już zrobiony dispatch i włożenie dodatkowej warstwy abstrakcji jest zbędne. Czy znacie jakieś dobre wzorce na tego typu problemy?

Zdaje sobie sprawę, że komunikacja po MQTT powinna wyglądać w inny sposób, ale przez pewne ograniczenia musi tak to wyglądać.

#programowanie #programista15k #cpp #iot #embedded

[Oo-oO]

@Parseval: zabawne, niewiele postów o embedded na wykopie, a jeszcze mniej o mqtt, a ja też wrzuciłem podobną rozkminę praktycznie w tym samym czasie. Ale do rzeczy. W sumie nie bardzo wiem o co ci chodzi - w sensie, rozumiem że działa to mniej więcej tak: przychodzi jakaś komenda z serwera, np zrób pomiar X, zrób pomiar Y, wysteruj Z? Słuchasz sobie rozumiem na tych tematach, dostajesz więc zdarzenie, system robi

[SpinOff]

@Parseval O MQTT przeczytałem 5 minut temu, ale może trochę pomogę. Nie podoba mi się w Twojej architekturze to, że zewnętrzny interfejs przenika do głębszych warstw abstrakcji. Głupia zmiana formatu wiadomości lub przeniesienie jakiegoś pola do innego requestu powoduje zmiany w serwerze, dispatcherze i kodzie modułów komunikujacych się z czujnikami.

Zewnętrzny interfejs zatrzymaj w aplikacji serwera i tam zrób logikę która będzie parsować requesty i na tej podstawie, delegować konkretne zadania do

[Parseval]

@Oo-oO: Faktycznie niezły przypadek z tymi postami :)

Dzięki Panowie za wyczerpujące odpowiedzi, generalnie komunikacja powinna odbywać się tak jak napsaliście. MQTT kładzie raczej nacisk na podejście asynchroniczne. Faktycznie obecnie jest tak, że jeśli zmieni się jakieś pole requesta, to pokłosiem tego są zmiany w zbyt wielu miejscach.

@SpinOff Chodzi mi tutaj o problem czysto software'owy, tzn. jak skonstruować buildera dla tych odpowiedzi. W tym przypadku chodzi mi o jakąś klasę

[Saly]

Chodzi mi tutaj o problem czysto software'owy, tzn. jak skonstruować buildera dla tych odpowiedzi. W tym przypadku chodzi mi o jakąś klasę abstrakcyjną albo inny twór bazujący na statycznym polimorfizmie, który na podstawie tego requesta zrobi to co napisałeś w punkcie 3.

@Parseval: jak nie masz wspólnego zachowania dla wiadomości to co możesz abstrachować? Powinieneś mieć dispatchera, który robi switch po typie wiadomości przychodzącej i tak robisz logikę dla każdej wiadomości