it-swarm.dev

Was sind die häufigsten Fehler und Anti-Patterns, die NHibernate-Benutzerprogrammierer machen?

Was sind die häufigsten Fehler und Anti-Patterns, die NHibernate-Benutzerprogrammierer machen? Bitte erläutern Sie, warum dies schlechte Praktiken sind, oder geben Sie einen Link zur Ressource zur weiteren Lektüre an.

Zum Beispiel:

  • Ein für neue NHibernate-Programmierer übliches Anti-Pattern ist die Verwendung von Identitäts-/nativen POIDs anstelle von ORM-Stil-Onces. Lesen Sie hier mehr ...
28

Meine persönlichen "häufig erklärten" Probleme:

Anti-Muster

Herumspielen mit getrennten Objekten (SaveOrUpdate oder Merge plus etwas chaotischen Code) anstatt DTOs zu verwenden. Je komplexer die Entitäten sind, desto chaotischer ist der Code. (Es bedeutet auch, dass es mit trivialen Entitäten recht gut funktioniert.) Ayende nennt es auch Stripper Pattern und erklärt das Kapselungsproblem.

Nicht verstehen Persistenz Ignoranz und Schreiben von NH-Anwendungen wie bei Verwendung von explizitem SQL. Symptom dafür: Aufrufen von Update nach dem Ändern eines Objekts, Fragen, warum Änderungen beibehalten werden, auch wenn Update nicht aufgerufen wurde, Fragen, wie vermieden werden kann, dass Änderungen beibehalten werden.

Nicht verstehen Transaktionen und das Muster der Arbeitseinheit . Häufige Anti-Patterns: implizite Transaktionen, Sitzung pro Operation und Sitzung pro Anwendung. Noch etwas lesen:

Verwenden von NH -Ereignissen zum Einfügen der Anwendungslogik (z. B. Änderungsverfolgung in Einfüge- und Aktualisierungsauslösern)

Erstellen Sie eine Klasse pro Tabelle . Einige Leute verstehen OOD nicht, andere verstehen relationales Design nicht.

Fehler

verwendung von eins zu eins anstelle von vielen zu eins. Ich habe versucht, es in diese Antwort zu erklären.

Verwenden von join fetch in Kombination mit SetMaxResult. Meine neuesten Antworten zu diesem Thema:

Schreiben sich selbst ändernder Entitäten . Wenn eine Entität den von NH festgelegten Wert nicht genau zurückgibt, wird sie als fehlerhaft betrachtet und in jeder Sitzung aktualisiert. Zum Beispiel: Ersetzen der persistenten NH-Sammlung in einem Eigenschaftssetter.

  IList<Address> Addresses
  {
    get { return addresses; }
    // will cause the addresses collection to be built up from scratch
    // in the database in every session, even when just reading the entity.
    set { addresses = new List<Address>(value); }
  }

  int Whatever
  {
    // will make the entity dirty after reading negative values from the db.
    // this causes unexpected updates after just reading the entity.
    get { if (whatever < 0) return 0; }
    set { whatever = value; }
  }

Vielleicht folgt mehr.

34

Das " N + 1 Problem auswählen ".

Hier führen Sie am Ende eine Auswahl für jede Entität aus, die Sie bearbeiten möchten (N), und eine Auswahl, um die Liste der Entitäten (+1) abzurufen, anstatt eine einzelne Auswahl aller Entitäten und ihrer Attribute.

5
Sean McMillan
  • Zu viele Abstraktionen
  • Keine Verwendung von Automappings mit FluentNHibernate
1
Sly

Versuchen Sie, es zu abstrahieren, damit Sie zu einem späteren Zeitpunkt zu Entity Framework (oder etwas anderem) wechseln können.

Das ist viel, viel schwieriger als die meisten Leute, die es versuchen, erkennen. Es gibt zahlreiche Unterschiede zwischen den beiden, die Sie auf eine Weise stolpern können, die manchmal sehr subtil sein kann. Es ist auch sehr ungewöhnlich, dass es am Ende tatsächlich benötigt wird - so sehr, dass Sie jahrelang akribisch versuchen können, es umzusetzen, bevor Sie feststellen, dass Ihr Ansatz völlig falsch ist.

Außerdem können Sie nicht viele nützliche und wichtige Funktionen von NHibernate verwenden, z. B. Caching der zweiten Ebene, Abfangen, Parallelitätsverwaltung, Änderungsverfolgung, Prefetch-Abfragen usw.

Wenn es wirklich notwendig wäre, zwischen NHibernate und Entity Framework zu wechseln, gäbe es ein aktiv entwickeltes Projekt, um dies auf GitHub (möglicherweise ähnlich wie CommonServiceLocator) mit zahlreichen Mitwirkenden und Pull-Anfragen zu unterstützen.

1
jammycakes