Producer–Controller–Presenter

Poziom: wszystkie poziomy.

Model dobieramy do systemu

Junexis nie narzuca jednego modelu architektury. Opisuje zadania, dane, komunikację i miejsca wykonania. Producer–Controller–Presenter jest jednym z pomocnych modeli porządkujących odpowiedzialności — tutaj używamy go jako przykładu. Nie każdy system potrzebuje tych trzech ról ani centralnego Controllera. PCP nie jest obowiązkowym etapem projektowania.

Producer–Controller–Presenter, w skrócie PCP, opisuje systemy, w których coś wytwarza dane, zaufana część interpretuje je i utrzymuje stan, a interfejs przedstawia człowiekowi zrozumiały obraz.

Przykład: kto odpowiada za alarm w magazynie?

Wróćmy do temperatury w magazynie z opisu działania Junexis. Czujnik dostarcza pomiar, serwer rozstrzyga, czy przekroczono próg, a panel pokazuje wynik.

Rola	Zadanie w przykładzie	Wynik
Producer — źródło danych	odczytuje temperaturę i przekazuje pomiar	pomiar temperatury
Controller — decyzje i stan	sprawdza pomiar i stosuje regułę alarmową	stan magazynu i decyzja o alarmie
Presenter — obraz dla człowieka	przedstawia wynik i stan połączenia	widok temperatury, alarmu albo braku aktualnych danych

Jeśli użytkownik chce zmienić próg alarmowy, panel wysyła żądanie do części odpowiedzialnej za decyzje. Ta sprawdza uprawnienia i poprawność wartości, zapisuje zaakceptowaną zmianę i przekazuje wynik do panelu.

To podział odpowiedzialności projektowanego systemu. Samo nadanie zadaniu roli Controllera nie dodaje automatycznie autoryzacji, bazy ani reguł alarmowych — trzeba je zaimplementować w obsługiwanej ścieżce wykonania.

Przepływ między odpowiedzialnościami

flowchart LR
    P["Producer<br/>wytwarza dane"] -->|"obserwacje i zdarzenia"| C["Controller<br/>decyzje i stan"]
    C -->|"projekcja systemu"| V["Presenter<br/>obraz dla człowieka"]
    V -.->|"intencja użytkownika"| C

W tym przykładzie role można przypisać do środowisk Junexis tak:

Producer              Controller                 Presenter
@embedded      →         @server         →          @report
dane                  decyzje i trwały stan      obraz systemu

To mapowanie przykładu, nie ograniczenie języka. PCP nie mówi, że każde zadanie @embedded musi być Producerem ani że @report może wyłącznie wyświetlać dane. Pomaga najpierw zobaczyć odpowiedzialności, zanim system otrzyma bardziej złożoną topologię.

Inne perspektywy i zasady ich weryfikacji opisuje katalog modeli mentalnych Junexis. Opis modelu nie oznacza automatycznie, że wszystkie jego warianty mają już działającą implementację.

Trzy odpowiedzialności

Producer — co się wydarzyło?

Producer obserwuje świat albo inne źródło i publikuje typowane dane:

pomiar czujnika,
zdarzenie urządzenia,
próbkę telemetrii,
komunikat z zewnętrznego systemu,
rezultat lokalnego obliczenia.

Producer powinien jasno określać znaczenie danych. Nie musi wiedzieć, jak zostaną pokazane człowiekowi ani w której tabeli zostaną zapisane.

Controller — co to znaczy i co należy zrobić?

Controller jest zaufaną granicą decyzji. Odbiera dane, stosuje reguły, koordynuje działania i utrzymuje źródło prawdy. W podstawowym przepływie z trwałym stanem to właśnie on:

sprawdza poprawność i uprawnienia,
podejmuje decyzję domenową,
zapisuje lub odczytuje trwały stan,
wybiera wynik przeznaczony dla interfejsu,
przyjmuje i rozstrzyga intencje użytkownika.

W Junexis rolę tę często realizują zadania @server. Nazwa Controller nie oznacza kontrolera konkretnego frameworka WWW — oznacza odpowiedzialność za politykę i stan systemu.

Presenter — co człowiek powinien zobaczyć?

Presenter otrzymuje typowaną projekcję i przedstawia ją w formie zrozumiałej dla użytkownika. Pokazuje również stan techniczny, taki jak oczekiwanie, rozłączenie, ponowne łączenie albo błąd.

Presenter może przyjąć działanie człowieka, ale nie omija Controllera. Wysyła typowaną intencję, którą Controller autoryzuje, wykonuje i dopiero wtedy utrwala.

Presenter nie zmienia źródła prawdy. Prosi Controller o wykonanie jawnej intencji.

Przepływ danych i intencji

sequenceDiagram
    participant P as Producer
    participant C as Controller
    participant D as Storage
    participant V as Presenter
    participant U as Użytkownik
    P->>C: typowana obserwacja
    C->>C: walidacja i decyzja
    C->>D: zapis lub odczyt
    D-->>C: wynik operacji
    C->>V: typowana projekcja
    V-->>U: obraz systemu
    U->>V: działanie człowieka
    V->>C: typowana intencja
    C->>C: autoryzacja i decyzja
    C->>D: kontrolowana zmiana
    C->>V: nowa projekcja

W uproszczonym wariancie z SQLite:

@embedded → @server → SQLite → @server → @report
                         ▲                    │
                         └── intencja ────────┘

SQLite nie jest współdzielonym plikiem otwieranym przez wszystkie części systemu. W zweryfikowanym pionie należy do @server. Producer dostarcza dane, a Presenter otrzymuje projekcję przez typowany kontrakt.

Dlaczego ten model jest użyteczny

PCP pasuje do wielu powszechnych systemów:

inteligentnego domu i IoT,
monitoringu maszyn,
telemetrii i pulpitów operacyjnych,
systemów alarmowych,
aplikacji biznesowych ze stanem i panelem WWW,
zarządzania flotą, robotami lub rojem,
przetwarzania danych przemysłowych,
usług zbierających zdarzenia i przedstawiających ich bieżący obraz.

Model porządkuje podstawowe pytania:

Pytanie	Odpowiedzialność
Kto wytworzył dane?	Producer
Kto interpretuje dane i jest właścicielem stanu?	Controller
Kto buduje obraz dla człowieka?	Presenter
Kto może zmienić źródło prawdy?	Controller po sprawdzeniu intencji
Jak części się komunikują?	typowane relacje Junexis

Ten sam model na trzech poziomach nauki

Poznaj

Użytkownik otrzymuje gotowy przepływ Producer → Controller → Presenter. Bezpieczne ustawienia pozwalają obserwować dane, decyzję, zapis i panel bez konfigurowania transportu oraz bazy.

Eksperymentuj

Użytkownik zmienia rytm Producenta, regułę Controllera, projekcję Presentera albo provider memory/SQLite. Odpowiedzialności pozostają czytelne, więc skutek każdej zmiany można prześledzić.

Przejmij kontrolę

Ekspert ustala gwarancje komunikacji, politykę storage, transakcje, timeouty, autoryzację intencji, recovery i rozmieszczenie. PCP nadal pomaga nazwać role, ale nie ukrywa rzeczywistej topologii.

Kiedy PCP nie pasuje

PCP nie musi być punktem wyjścia. Inny podział odpowiedzialności może być czytelniejszy, gdy:

urządzenie musi podejmować autonomiczne decyzje bez serwera,
wiele Producerów współpracuje bez jednego Controllera,
zadania serwerowe również wytwarzają nowe strumienie danych,
system ma wielu Controllerów i rozdzielone źródła prawdy,
komunikacja zachodzi bez udziału człowieka i Presentera,
potrzebna jest orkiestracja, pipeline analityczny albo model zdarzeniowy.

Wtedy PCP pozostaje pomocną perspektywą, ale nie powinien być wciskany w system na siłę. Junexis opisuje rzeczywiste zadania i relacje, a nie narzuca jednej architektury.

Zastosuj model

Moduły, providery i SQLite pokazują PCP dla trwałego stanu.
Przewodnik: moduły i baza danych prowadzi przez implementację.
Laboratorium inteligentnego domu rozwija podobny przepływ etapami Poznaj, Eksperymentuj i Przejmij kontrolę.
Jak działa Junexis umieszcza model w całej drodze od źródła do artefaktu.