2008-12-04 27 views
8

Ich frage mich, wie ich NHibernate mitteilen kann, um Abhängigkeiten von meinen POCO-Domänenobjekten aufzulösen.Abhängigkeitsinjektion mit NHibernate-Objekten

Ich fand heraus, dass Methoden wie CalculateOrderTax im Domain-Objekt sein sollten, weil sie Domain-spezifische Geschäftsregeln kodieren. Aber wenn ich zwei davon habe, verletze ich SRP.

Es wäre kein Problem, diese Methoden zu Strategy-Klassen zu extrahieren, aber ich frage mich, wie man NHibernate diese laden kann.

Es scheint keine gute Lösung zu sein, eine Liste von Objekten im Repository durchzulaufen, um auf Dependency basierende Injektion zu erhalten/setzen, bevor das Objekt an die höheren Ebenen übergeben wird.

Ich benutze auch Castle Windsor für meine Depency-Injektion jetzt.

Antwort

8

Ich habe Abfangjäger für ähnliche Aufgaben mit:

Ein Abfangjäger, die geladenen Einheiten modifiziert:

public class MyInterceptor : EmptyInterceptor 
{ 
    public override bool OnLoad(object entity, object id, object[] state, string[] propertyNames, IType[] types) 
    { 
     return InjectDependencies(entity as MyEntity); 
    } 
} 

Mitarbeiterin mit einer Sitzung:

nhSessionFactory.OpenSession(myInterceptor); 

ich auch habe gelesen Irgendwo, dass es in der kommenden 2.1-Version bessere Unterstützung für die benutzerdefinierte Konstruktorinjektion geben würde, aber ich kann die Referenz momentan nicht finden.

+0

Fabio (aktueller Lead-Programmierer) erklärt die neue Konstruktor-Injektion hier: http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html –

+0

Dies ist, was ich vorhabe, auch zu tun. Können Sie die Verwendung des OnLoad-Ereignisses anstelle der Instanziierung rechtfertigen? –

+0

Es scheint, Instanziierung ist eine Möglichkeit, Ihre eigene Fabrik zu machen (was sehr nett sein könnte, wenn Sie Konstruktor-Injektion verwenden möchten). Ich brauchte nur einen Dienst in eine überschreibbare Basisklasse zu injizieren. –

1

Da niemand in der Lage scheint, Ihre Frage im Moment zu beantworten, dachte ich, ich würde vorschlagen, Ihren Code neu zu strukturieren, um die Notwendigkeit zu beseitigen, dass der Auftrag seine eigene Steuer berechnet.

Sie könnten es an einen OrderTaxService delegieren, der ein Order-Objekt übernimmt und ein OrderValue-Objekt oder etwas in diesen Zeilen zurückgibt.

Dadurch bleibt die Logik in Ihrer Domäne erhalten, Sie müssen sie jedoch nicht mehr an Ihre Auftragsobjekte anhängen.

+0

So mache ich es jetzt. Ich gebe die Reihenfolge ständig weiter und lasse externe Klassen Dinge berechnen. Es fühlt sich einfach falsch an, weil meine Objekte a) veränderbar sind und b) Ich muss diese Dienste ständig mit mir herumtragen, wenn ich sie nicht aus dem Business-Logik-Code herausholen will. – Tigraine

+0

Es wird schwieriger, wenn es mehrere Strategien für eine Sache gibt. Wie Aufträge mit normalTaxrate werden anders als andere berechnet. Ich muss dann die Dienste entscheiden lassen, wie Steuern für ein bestimmtes Domänenobjekt berechnet werden. .. – Tigraine

1

Ich stimme Garry zu, dass Sie Dienstabhängigkeiten so weit wie möglich von Ihren Domänenobjekten entfernen sollten. Manchmal macht es Sinn, zum Beispiel Verschlüsselung/Entschlüsselung. In diesem Fall können Sie es mithilfe von interception oder IUserType in der Infrastruktur verbergen. Ich denke, Letzteres ist günstig, wenn Sie es verwenden können. This article zeigt im Detail, wie es geht. Ich mache das und es funktioniert ganz gut.

Verwandte Themen