Sequelize orm vs Loopback orm

Question

Ich erstelle Rest api von PostgreSQL unterstützt. Ich mag Strongloop Loopback Framework, es rationalisiert die API-Entwicklung. Aber wie sein eingebauter Orm im Vergleich zu Sequelize? Welche erweiterten Funktionen sind als dedizierte SQL-ORM-Dateien, die im Loopback fehlen, fortbestehen? Vielleicht ist es besser, mit Sequelize zu bleiben, und einige andere Ruhe-API-Helfer als Monolith-Loopback-Framework zu verwenden?

Answer 1

Art einer Meinungsfrage, weiß nicht, ob es wirklich hierher gehört. Ich sehe nicht viel Unterschied in der ORM-Implementierung selbst, soweit das RDMBS-Stück sowieso geht (nosql ist eine andere Geschichte). Ich kann auch nicht wirklich für die Postgres-Implementierung sprechen, da ich sie leider mit MSSQL verwenden muss. Kann Squelize Sie mit Hstore oder Json arbeiten? Denken Sie an die Dinge, die Sie im Loopback vermissen werden, da es die API über alle Connectors verallgemeinert hat. Es ist ein Kompromiss. Sie fragen Ihre RDMBS auf dieselbe Weise ab wie Mongo, sagen wir mal. Das heißt, strongloop scheint hier ein Produkt für das Unternehmen entwickelt zu haben, also würde ich wetten, dass die Unterstützung ziemlich gut sein sollte.

Nebenbei bemerkt, ich weiß nicht wirklich, ob Aufruf von Loopback ein monolithischer Rahmen ist genau. Für mich wäre ein monolithisches Framework so etwas wie Rails, das dich in eine Ecke der Architektur einbläst und eher auf Server gerenderten Inhalt ausgerichtet ist (vs Fat-Client SPAs). Loopback generiert automatisch eine Swagger-konforme Rest-API für Sie, obwohl es Ihnen überlassen ist, zu konfigurieren, auf welche Routen/Verben zugegriffen werden kann und welche ACL-Steuerelemente verwendet werden. Während bestimmte Umsetzung der Stücke "eingebrannt" sind, ist es kaum monolithisch. Sie werden am Ende alle diese Routen in einem anderen Rahmen erstellen, wenn Sie mit einer Restful-Architektur gehen. Sie können nach wie vor benutzerdefinierte Endpunkte im Loopback erstellen. Eine wirklich nette Sache mit Loopback ist, dass Sie Modelldefinitionen aus vorhandenen/älteren Sets in RDBMS reverse-engineeren können. Es gibt auch eine Definitions-Sync-Option (ich habe es noch nicht erforscht). Check out this talk, es zeigt gut die Logik, warum Loopback ist.

Answer 2

Es ist erwähnenswert, dass Loopback KEINE referenzielle Integrität garantiert, da Fremdschlüssel auf DB-Ebene nicht erzwungen werden. siehe https://github.com/strongloop/loopback-connector-mysql/issues/135

Answer 3

Es ist ein bisschen spät Antwort, aber für zukünftige Referenzen: Loopback ist mehr als ORM, es ist ein ORM + Express, in der Tat. Sie können Loopbacks ORM lib (loopback-datasource-juggler) auch separat verwenden, aber api ist nicht so intuitiv wie Sequelize. Auf der anderen Seite war für mich eines der wichtigsten Unterscheidungsmerkmale, dass Loopback die vorhandenen Datenbanktabellen aktualisieren kann, ohne die darin enthaltenen Daten zu zerstören, wenn Sie später Ihr Modell ändern. Mit Sequelize müssen Sie es manuell behandeln, es erstellt die Tabelle erst beim ersten Mal, wenn Sie es ausführen. Um die vorhandene Tabelle zu aktualisieren, müssen Sie sie löschen und neu erstellen. Und hoffentlich erinnern Sie sich daran, ein Backup der Daten in der Tabelle zu bekommen. Oder ändern Sie die Struktur der Tabelle manuell.

Der Grund dafür, dass Loopback es leicht handhabt, ist, anders als Sequelize, nicht die Datenintegrität auf der Datenbankebene zu erzwingen, wie @ gurg-hackpof oben erwähnt.