Iniezione di una fabbrica con più parametri del costruttore

Question

Iniezione di una fabbrica con più parametri del costruttore

#1 da (1 voti)
#2 da (0 voti)

0

Inizialmente avevo bisogno di una sola coda per essere creata da MessageQueueFactory :

container.RegisterSingleton<IMessageQueueFactory>(() => {
    var uploadedWaybillsQueuePath = ConfigurationManager
        .AppSettings["msmq:UploadedDocumentsQueuePath"];
    return new MessageQueueFactory(uploadedWaybillsQueuePath);
});

Ora che i requisiti sono cambiati, è necessario supportare diverse code.

La cosa più semplice che posso fare qui è aggiungere altri percorsi (memorizzati in app.config ) al costruttore della factory e fornire i metodi per ogni coda:

container.RegisterSingleton<IMessageQueueFactory>(() => {
    var uploadedDocsQueuePath = ConfigurationManager
        .AppSettings["msmq:UploadedDocumentsQueuePath"];
    var requestedDocsQueuePath = ConfigurationManager
        .AppSettings["msmq:RequestedDocumentsQueuePath"];

    return new MessageQueueFactory(
        uploadedWaybillsQueuePath,
        requestedDocsQueuePath
    );
});

interface IMessageQueueFactory {
    MessageQueue CreateUploadedDocsQueue();
    MessageQueue CreateRequestedDocsQueue();
}

È un design scadente? Come può essere refactored?

c# dependency-injection .net

posta lexeme 07.06.2016 - 16:45

fonte

2 risposte

0

Mi sembra in gran parte ok. Non c'è niente da dire che una fabbrica dovrebbe avere un solo metodo per la creazione.

Il libro Gang-of-Four contiene in particolare esempi in cui una fabbrica crea famiglie di oggetti (penso che l'esempio fossero i widget della GUI per diverse piattaforme, ad esempio finestre / pulsanti Motif contro finestre / pulsanti OpenLook o simili). Dal libro (e il link sopra):

This is an Abstract Factory. A regular factory creates concrete objects of one type. An abstract factory creates concrete objects of varying types, depending on the concrete implementation of the factory itself. Its ability to focus on not just concrete objects, but entire families of concrete objects "distinguishes it from other creational patterns, which involve only one kind of product object" (pp51).

risposta data 07.06.2016 - 16:59

fonte

Leggi altre domande sui tag c# dependency-injection .net

Nome di un simbolo in rubino "serializzazione" irreversibile efficiente?

score 1 · Accepted Answer

Potresti avere classi separate per ogni coda e iniettarle, invece di iniettare la fabbrica. Il tuo progetto come descritto qui non ha bisogno di una fabbrica oltre il contenitore IoC in quanto il tipo di coda può essere determinato in fase di compilazione.

Le classi che hanno bisogno di accedere alla coda possono semplicemente richiedere un IUploadedDocsQueue o IRequestedDocsQueue come parametro del costruttore. L'effettiva implementazione di tali interfacce potrebbe essere eseguita da una singola classe che avvolge il MessageQueue incorporato e implementa entrambe le interfacce, o da una singola classe astratta che avvolge MessageQueue ed è ereditata da due classi concrete che implementano dette interfacce.

Questo design aderisce maggiormente al Principio di Responsabilità Unico rispetto al progetto qui delineato. Quando è necessario aggiungere un'altra coda al progetto corrente, è necessario modificare la fabbrica. Con una classe per coda, si aggiunge semplicemente un'altra classe. L'utilizzo delle interfacce ti consente anche di deridere e svitare il tuo codice molto più facilmente, dubito che tu possa prendere in giro efficacemente la classe MessageQueue integrata ...