2009-05-23 11 views
8

Ich habe eine IValueConverter implementiert Klasse und ich muss es mit meinem DI-Container (Ninject) injiziert werden.Wie injiziere ich einen Konverter in XAML

Das Problem ist, in XAML gibt es keine sofort offensichtliche Möglichkeit, Kontrolle über die Instantiierung des Converter-Objekts zu erhalten.

So enthält meine XAML einer Zeile wie folgt aus:

Source = "{Binding Path = CurrentMessage, Converter = {Static ImagePathConverter}}"

Wo die ImagePathConverter wird für mich geschaffen werden.

Ich nehme an, ich könnte eine statische Klasse "Service Locator" erstellen und sie aufrufen, um meine Abhängigkeit aufzulösen und die StaticResource in eine Eigenschaft "MyServiceLocator.TheImageConverter" zu ändern, aber das bringt mich zum Erbrechen.

Ich hoffe, dass diese Frage mit ein paar Codeschnipsel beantwortet werden kann, die speziell auf den bereitgestellten Code abzielen - und vielleicht einen unterstützenden Link zu einem Beispiel. Nicht einfach eine Empfehlung, irgendwo hinzuschauen.

Auch, sehr wichtig, nehme an, dass der XAML keinen Code-Behind hat - und dass ich keinen verwenden kann. Ich erstelle eine Haut und möchte keinen Code hinter sich. Also kann ich keine Klassenvariable im Klassenkonstruktor setzen und darauf verweisen. Vielleicht ist das unvernünftig, ich bin mir noch nicht sicher.

+0

Ich bin interessiert zu wissen, warum Sie den Konverter müssen mit DI gelöst werden ..? – NotDan

+0

Da der Konverter (abhängig) von einer Formatierungsklasse verwendet, die eigene Abhängigkeiten hat und diese Abhängigkeiten ebenfalls Abhängigkeiten aufweisen können. Das ist der springende Punkt von DI - all diese Abhängigkeiten für mich zu verkabeln. Ich frage mich, ob viele Leute es nur zu neuen Objekten verwenden und den Hauptzweck nicht erkennen? – PandaWood

Antwort

8

Ein üblicher Weg, dies zu handhaben, ist, dass Ihr Konverter auch ein MarkupExtension ist. Das heißt:

public class MyConverter : MarkupExtension, IValueConverter 

Ihre ProvideValue() Methode eine Instanz des Wandlers zurückkehren können, so dass Sie es wie folgt verwenden:

Source="{Binding CurrentMessage, Converter={local:MyConverter SomeParameterToConverter}}" 

Dies ist nicht wirklich etwas mit DI zu tun, aber es adressiert Ihre Anforderung, den Code dahinter zu beseitigen. Ich sehe nicht wirklich den Sinn, dass Konverter mit Ihrem DI-Container registriert werden.

+1

Danke, es ist eine faire Sorge um Konverter. Wenn ich nicht die Punkte sehen kann, in denen Konverter mit dem DI-Container registriert sind, dann nehme ich an, dass der DI-Container gerade für "neue" Objekte verwendet wird. Der Punkt ist, dass die betreffende Konverter-Klasse andere Abhängigkeiten hat, die nur durch den DI-Container aufgelöst werden können (zB "configuration" -Objekte im Singleton-Bereich registriert) – PandaWood

+0

Ich denke, das ist eine gute Antwort, wenn ich den Fehler beheben kann ' Fehlender XmlNamespace, Assembly oder ClrNamespace in der Mapping-Anweisung 'Ich werde darauf zurückkommen (dh trotz Hinzufügen von xmlns: local = "clr-namespace: MyNamespace" – PandaWood

+1

Verstanden, der Fehler ist behoben und es funktioniert gut. Ich musste noch anrufen meine DI in einer Service-Locator-Mode in der ProvideValue-Methode, aber ich glaube nicht, dass es einen Weg dorthin gibt) – PandaWood

Verwandte Themen