Come applicare DI sulla classe astratta con molti bambini

0

Ho sviluppato un'applicazione che legge un file, lo mappa e memorizza le informazioni sul database. Per alcune colonne abbiamo bisogno della chiave primaria di un oggetto nel database e, se il record non esiste, dobbiamo crearlo, per questo abbiamo ottenuto una classe chiamata ReferenceSolver che è astratta e ha molte implementazioni che controlleranno se l'oggetto esiste e crea se necessario.

Poiché voglio che l'operazione sia atomica e crei il main e l'oggetto e gli oggetti di riferimento in una transazione, sto usando una classe chiamata TransactionBuilder a cui passo tutte le query che voglio eseguire. Il problema che ho riscontrato è che non so come passare il riferimento a TransactionBuilder a ogni figlio di ReferenceSolver, ho lavorato attorno ad esso usando un Singleton ma ho sollevato molte bandiere rosse sulla mia testa.

La logica nel metodo pertinente per ReferenceSolver piace in:

private string GetReferencedObjectKey(
        string referenceValue, 
        Dictionary<string, string> record
) {
    SQLConnector connector = new SQLConnector( LogImporter.ConnectionString );

    using (
        var reader = connector.ExecuteQuery(
            string.Format(
                "SELECT W6Key FROM {0} WHERE {1} = '{2}'", 
                TableName, 
                ReferenceField, 
                referenceValue
            )
        )
    ) {
        if ( reader.Read() ) { 
            return reader["W6Key"].ToString(); 
        } else {
            int key = KeyHelper.GetNextFreeKey(TableName);
            transactionBuilder.ExecuteQuery( GetInsertQuery() );

            return key.ToString();
        }
    }
}

C'è un modo per passare la stessa istanza dell'oggetto senza usare un singleton a cui non ho pensato ?? Ho anche pensato di creare un evento per richiedere la creazione dell'oggetto, ma non sono sicuro che sia una buona soluzione.

    
posta Zalomon 30.01.2018 - 18:25
fonte

1 risposta

3

Se la tua classe ReferenceSolver è simile a questa

abstract class ReferenceSolver
{
     private TransactionBuilder transactionBuilder;

     protected ReferenceSolver(TransactionBuilder tb)
     {
         transactionBuilder=tb;
     }
}

quindi rendi la tua classe figlia simile a

class ChildReferenceSolver : ReferenceSolver
{

     public ChildReferenceSolver(TransactionBuilder tb)
         :ReferenceSolver(tb)
     {
     }
}

Quindi il codice in quelle classi figlie non può accedere al membro transactionBuilder privato. E non può essere facilmente dimenticato, dal momento che il processo di costruzione per ogni bambino richiede ora di passare un oggetto TransactionBuilder. Assumiamo che questa costruzione di quei ChildReferenceSolver s sia fatta in una qualche classe factory che ha accesso all'oggetto TransactionBuilder inizializzato (o in realtà la costruzione), questa intera costruzione sarà sempre in un posto.

    
risposta data 31.01.2018 - 18:51
fonte

Leggi altre domande sui tag