Ich finde beide Lösungen zur Sichtbarmachung des Adapter-Instanzobjektes adpater in eigenen Modulen haben Ihre Berechtigung. Die Lösung von AlCalzone finde ich sehr elegant, insbesondere dann, wenn ich das instanzierte Adapterobjekt noch dynamisch anpassen möchte (z.B. einige Methoden promisifizieren möchte, etc.). Dann kann ich das schön übersichtlich in global.js machen. Wenn ich nur adapter in wenigen eigenen Modulen benötige, mache ich es eigentlich immer so, wie von apollon77 vorgeschlagen. Das geht schnell und ist sehr überschaubar. Bei der Lösung von AlCalzone muss mann sich immer bewusst machen, dass Klassen erst ab Nodeversion 4.8.3 zur Verfügung stehen, dass eine Kompatibilität zur Nodeversion 0.12.18, die ja auch noch vielfach genutzt wird, nicht gegeben ist.
Im Umgang mit adapter sollte man auch wissen, dass mit
const utils = require(path.join(__dirname, '/lib/utils'));
var adapter = utils.adapter(options);
am Anfang von main.js die Erzeugung von adapter asynchron erfolgt. Dies liegt an dem Aufruf von
initObjects(callback);
innerhalb des Adapter-Konstruktors. Hierdurch werden im adapter alle Methoden in
adapter.objects
adapter.states
(in der Regel als ObjectsInMemClient und StatesInMemClient) für die Abstraktionsschicht zur Verfügung gestellt.
Das hat zur Folge, dass z.B. folgender Aufruf am Anfang von main.js
const Promise = require('bluebird');
const utils = require(path.join(__dirname, '/lib/utils'));
var adapter = utils.adapter(options);
adapter = Promise.promisifyAll(adapter);
nicht vollständig funktionieren muss, da adapter.states zu diesem Zeitpunkt noch nicht erzeugt wurde.
Man muss also immer das ready-Event abwarten, um Änderungen in adapter vorzunehmen, d.h. erst in main() ist wirklich sichergestellt, dass adapter vollständig zur Verfügung steht.
Grüße
Carsten
