2009-05-23 17 views
8

Ho una classe IValueConverter implementata e ne ho bisogno per essere iniettata usando il mio contenitore DI (Ninject).Come iniettare un convertitore in XAML

Il problema è che in XAML non esiste un modo immediatamente ovvio per ottenere il controllo sull'istanza dell'oggetto Convertitore.

Quindi il mio XAML contiene una riga simile a questa:

Source = "{Binding Path = CurrentMessage, convertitore = {StaticResource ImagePathConverter}}"

Dove, il ImagePathConverter volontà essere creato per me.

Suppongo di poter creare una classe statica "localizzatore di servizi" e chiamarla per risolvere la mia dipendenza e modificare StaticResource in una proprietà "MyServiceLocator.TheImageConverter", ma questo mi fa venire voglia di vomitare.

Spero che questa domanda possa essere risolta con alcuni frammenti di codice che mirano specificamente al codice fornito - e forse un link di supporto ad un esempio. Non solo una raccomandazione per dare un'occhiata da qualche parte.

Inoltre, aspetto molto importante, supponiamo che XAML non disponga di codice code e che non possa utilizzarne uno. Sto creando un skin e non voglio un codice dietro. Quindi non posso impostare una variabile di classe nel costruttore della classe e farvi riferimento. Forse è irragionevole, non ne sono ancora sicuro.

+0

mi interessa sapere perché è necessario il convertitore da risolvere con DI ..? – NotDan

+0

Poiché il convertitore utilizza (dipende) una classe di formattazione, che ha dipendenze proprie e ognuna di queste dipendenze può avere anche dipendenze. Questo è l'obiettivo principale di DI: collegare tutte queste dipendenze per me. Mi chiedo se molte persone lo stanno usando solo per oggetti nuovi e non si rendono conto dello scopo principale? – PandaWood

risposta

8

Un modo comune per gestire questo è che il convertitore sia anche un MarkupExtension. Cioè:

public class MyConverter : MarkupExtension, IValueConverter 

Il tuo metodo ProvideValue() può restituire un'istanza del convertitore, in tal modo consentendo di utilizzare in questo modo:

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

Questo non è davvero nulla a che fare con la DI, ma risponde al tuo obbligo di eliminare il codice. Non vedo davvero il punto di avere i convertitori registrati con il tuo contenitore DI.

+1

Grazie, è una giusta preoccupazione per i convertitori. Non vedendo i punti in cui i convertitori sono registrati con il contenitore DI, penso che si assuma che il contenitore DI sia usato solo per oggetti "nuovi". Il punto è che la classe del convertitore in questione ha altre dipendenze che possono essere risolte solo dal contenitore DI (ad esempio oggetti "di configurazione" registrati nello scope Singleton) – PandaWood

+0

Penso che questa sia una buona risposta, quando posso correggere l'errore " Manca XmlNamespace, Assembly o ClrNamespace in Mapping instruction 'Tornerò ad esso (cioè nonostante aggiungendo xmlns: local = "clr-namespace: MyNamespace" – PandaWood

+1

Trovato! Risolto l'errore e funziona bene. la mia DI in modalità service locator nel metodo ProvideValue, ma non credo che ci sia un modo per aggirare questo) – PandaWood

Problemi correlati