Iniezione del costruttore rispetto all'iniezione sul campo

2

So che questo argomento è già stato discusso molto, quindi non voglio entrare in quale sia il "modo migliore".

Ho utilizzato l'iniezione sul campo per un paio d'anni, ma recentemente ho scoperto che molte persone preferiscono l'iniezione del costruttore perché i collaboratori di una classe devono essere impostati in modo esplicito prima di poter creare un'istanza di una classe.

Un argomento da utilizzare per l'iniezione del costruttore è che ti fa pensare a quante classi stai effettivamente dipendendo. Ho esaminato le classi in uno dei miei progetti per vedere se ho troppe dipendenze.

Ho notato che una mia classe aveva circa 6 dipendenze, quando le fornisco tramite il costruttore ottengo un costruttore davvero brutto. Questo mi fa pensare che potrei dipendere troppo da qui.

Se ci penso comunque, non penso che abbia senso in questo caso dividere la classe in quelle più piccole.

Il caso è questo:

Esiste una classe di servizio con un metodo "createContract" che accetta l'input da un modulo e stipula un contratto con i dati forniti.

Il modulo ha 5 menu a discesa in cui scegli determinati codici / tipi per quel contratto. Ognuno corrisponde a un'entità separata memorizzata in un'altra tabella di database.

class FormData {
    private String aFieldOnTheContract
    private String fictiveCode1Id;
    private String fictiveCode2Id;
    private String fictiveCode3Id;
    private String fictiveCode4Id;
    private String fictiveCode5Id;
}

Più avanti nel servizio quando voglio creare questo contratto, uso 5 classi "XyzRepository" per cercare l'entità con l'id di quello che hai selezionato nel modulo.

Non sono sicuro di come potrei cambiare il mio design per non doverlo fare ed essere in grado di rimuovere queste 5 dipendenze. Qualche idea?

    
posta geoffreydv 01.04.2016 - 09:25
fonte

1 risposta

4

Metti tutti i dati di accesso per i tuoi codici su un singolo repository

Se i codici sono abbastanza simili, potresti essere in grado di limitarti a un singolo repository che ha cinque diversi metodi GET, o anche un singolo metodo generico che accetta il tipo di entità come argomento. Quest'ultimo è simile a quello che effettivamente fa NHibernate: si ha l'unico oggetto Session che ha un metodo Get generico che consente di recuperare qualsiasi entità mappata da id in modo strongmente tipizzato.

Questo potrebbe funzionare meglio se i tuoi codici hanno una sorta di classe genitrice condivisa poiché puoi creare un repository chiamato dopo il genitore e avere metodi separati su quello per bambino.

Inserisci i codici su uno o più componenti

Non inserendo le cinque entità direttamente nel Contratto ma utilizzando una classe che contiene solo quelle entità e inserendole in Contratto, puoi avere una singola classe che mappa solo i codici sulla classe separata. La classe che esegue la mappatura richiede ancora i cinque repository, ma qualsiasi altra classe che deve mappare le cinque entità può semplicemente utilizzare la classe.

Se vuoi ancora sbarazzarti dei cinque repository, verifica se è possibile raggruppare i codici su più classi separate. È probabile che almeno alcuni dei codici siano correlati, ma ciò dipende strongmente dal tuo dominio.

    
risposta data 01.04.2016 - 10:24
fonte

Leggi altre domande sui tag