Az Node.js eseményeinek megfelelő használata

Mielőtt az eseményvezérelt programozás népszerűvé vált, az alkalmazás különböző részei közötti kommunikáció szokásos módja meglehetősen egyszerű volt: egy olyan komponens, amely üzenetet akart küldeni egy másiknak, kifejezetten meghívta az adott összetevő metódusát. De az eseményvezérelt kódot úgy írják, hogy reagáljon, és ne hívjon .

Az események előnyei

Ez a megközelítés összetevőinket sokkal jobban leválasztja . A pályázatírás folytatása közben azonosítjuk az eseményeket. A megfelelő időben kirúgjuk őket, és mindegyikhez egy vagy több eseményhallgatót csatolunk . A funkcionalitás bővítése sokkal könnyebbé válik. Több hallgatót is hozzáadhatunk egy adott eseményhez. Nem manipuláljuk a meglévő hallgatókat vagy az alkalmazás azon részét, ahonnan az eseményt kilőtték. Amiről beszélünk, az a Figyelő minta.

Eseményalapú építészet tervezése

Az események azonosítása nagyon fontos. Végül nem akarjuk eltávolítani / kicserélni a meglévő eseményeket a rendszerből. Ez arra kényszeríthet minket, hogy töröljük / módosítsuk az eseményhez csatolt tetszőleges számú hallgatót. Az általánosan alkalmazott elv az, hogy csak akkor fontolom meg az esemény indítását, amikor az üzleti logika egysége befejezi a végrehajtást.

Tehát mondjuk, hogy egy csomó különféle e-mailt szeretne elküldeni a felhasználó regisztrációja után. Most maga a regisztráció sok bonyolult lépést és kérdést tartalmazhat. De üzleti szempontból ez egy lépés. És a kiküldendő e-mailek mindegyike egyedi lépés. Tehát lenne értelme egy eseményt lőni, amint a regisztráció befejeződik. Több hallgató is csatlakozik hozzá, akik mindegyikük felelős egyfajta e-mail küldéséért.

A Node aszinkron, eseményvezérelt architektúráján vannak bizonyos típusú objektumok, amelyeket „kibocsátóknak” neveznek. Nevezett eseményeket bocsátanak ki, amelyek a „hallgatóknak” nevezett funkciókat idézik elő. Minden eseményt kibocsátó objektum az EventEmitter osztály példánya. Használatával saját eseményeket hozhatunk létre:

Egy példa

A hozzáféréshez használjuk a beépített eseménymodult (amelyet arra kérek, hogy nézze meg részletesen) EventEmitter.

Ez az alkalmazás azon része, ahol szerverünk HTTP-kérést kap, új felhasználót ment és eseményt bocsát ki:

És egy külön modul, ahová hallgatót csatolunk:

Jó gyakorlat elkülöníteni a politikát a végrehajtástól. Ebben az esetben a házirend azt jelenti, hogy mely hallgatók mely eseményekre vannak feliratkozva. A megvalósítás magukat a hallgatókat jelenti.

Ez a szétválasztás lehetővé teszi, hogy a hallgató is újrafelhasználhatóvá váljon. Csatolható más eseményekhez, amelyek ugyanazt az üzenetet (felhasználói objektumot) küldik ki. Fontos megemlíteni azt is, hogy ha egy eseményhez több hallgató kapcsolódik, akkor azokat szinkronban és a csatolás sorrendjében hajtják végre . Ezért a végrehajtás befejezése someOtherListenerután fog futni sendEmailOnRegistration.

Ha azonban azt akarja, hogy a hallgatók aszinkron futtassanak, egyszerűen így burkolhatja a megvalósításokat setImmediate:

Tartsa tisztán a hallgatóit

Tartsa be az egységes felelősség elvét a hallgatók írásakor. Egy hallgatónak csak egy dolgot kell tennie, és jól kell tennie. Kerülje például, hogy ne írjon túl sok feltételt egy hallgatón belül, amely az esemény által továbbított adatok (üzenet) függvényében dönti el, mit tegyen. Sokkal helyesebb lenne különféle eseményeket használni abban az esetben:

A hallgatók kifejezetten leválasztása, ha szükséges

Az előző példában hallgatóink teljesen független funkciók voltak. De azokban az esetekben, amikor a hallgató egy objektumhoz van társítva (ez egy módszer), manuálisan le kell választani a feliratkozott eseményekről. Ellenkező esetben az objektum soha nem lesz szemétgyűjtő, mivel az objektum egy részére (a hallgatóra) továbbra is hivatkozni fog egy külső objektum (az emitter). Így a memória szivárgásának lehetősége.

Például, ha csevegőalkalmazást építünk, és felelősséget akarunk látni egy értesítés megjelenítéséért, amikor új üzenet érkezik egy csevegőszobába, amelyhez a felhasználó csatlakozik, magában a felhasználói objektumban kell lennie, akkor ezt tehetjük:

Amikor a felhasználó bezárja a fülét, vagy egy időre megszakad az internetkapcsolata, természetesen érdemes visszahívást indítanunk a szerver oldalon, amely értesíti a többi felhasználót arról, hogy egyikük éppen offline állapotba került. Ezen a ponton természetesen nincs értelme displayNewMessageNotificationfelhívni az offline felhasználóra. Továbbra is új üzeneteket hívunk meg, hacsak nem távolítjuk el kifejezetten. Ha nem, a felesleges hívást leszámítva a felhasználói objektum is a végtelenségig a memóriában marad. Tehát mindenképpen hívja disconnectFromChatroombe a szerver oldali visszahívást, amely akkor hajtódik végre, amikor a felhasználó offline állapotba kerül.

Óvakodik

Az eseményvezérelt architektúrák laza összekapcsolása fokozott bonyolultsághoz is vezethet, ha nem vagyunk óvatosak. Nehéz lehet nyomon követni a rendszerünk függőségeit. Alkalmazásunk különösen hajlamos lesz erre a problémára, ha elkezdünk eseményeket bocsátani a hallgatók belsejéből. Ez kiválthatja a váratlan események láncolatát.