Progettazione delle interfacce dei moduli

5

Sto studiando ingegneria del software e una cosa che sto cercando di migliorare è la mia abilità nell'architettura software. La mia domanda è abbastanza ampia, quindi cercherò di spiegarlo con un esempio.

Supponiamo di avere un livello del modello e un livello di servizio. Il modello gestisce varie entità (come utenti, prodotti, ordini, campains ecc.). I servizi forniscono funzionalità quali valutare l'efficacia di una campagna e utilizzano diversi moduli del livello del modello per accedere ai dati richiesti.

In che modo e quando specifichi tali dipendenze? Vedo le seguenti possibilità:

  • Consenti l'accesso generale a tutti i modelli. Questo è l'approccio adottato in molti framework MVC, in cui i controllori possono accedere a qualsiasi classe di modello.

    Pro: non devi specificare le dipendenze, lo sviluppatore che scrive il controller è molto flessibile.
    Contro: se vuoi testare un servizio , non sai davvero quale modello devi prendere in giro perché il servizio potrebbe usare tutto. Queste dipendenze implicite possono anche rendere la manutenzione un dolore.

  • I servizi specificano esplicitamente i modelli richiesti. I sistemi di gestione delle dipendenze come requirejs o CommonJS richiedono il lavoro in questo modo.

    Pro: nessuna dipendenza implicita semplifica la manutenzione
    Contro: la deduzione è impossibile. Quando si progetta il modulo, è necessario sapere esattamente di cosa avrà bisogno il modulo. Se in seguito noti che hai bisogno di un'altra interfaccia, devi cambiare l'architettura.

  • Specifica le interfacce esplicite che verranno fornite al servizio. Chiunque installi il servizio dovrà fornire implementazioni delle interfacce. Penso che l'iniezione di dipendenza funzioni in questo modo, sebbene l'iniezione sia automatizzata lì.

    Pro: nessuna dipendenza implicita semplifica la manutenzione, i test sono semplificati, perché sai esattamente cosa deridere.
    Contro: Quando si progetta il modulo, è necessario sapere esattamente di cosa avrà bisogno il modulo. Se in seguito noti che hai bisogno di un'altra interfaccia, devi cambiare l'architettura.

In teoria, l'iniezione di dipendenza sembra il modo migliore. Ma è pratico specificare ogni requisito? Quanto dovrebbe essere fine? Per entità? Raggrupparli? O una dipendenza per "cosa puoi fare con un'entità"?

Ci sono semplicemente troppe possibilità e mi piacerebbe avere qualche consiglio del mondo reale.

    
posta Yogu 16.07.2014 - 19:39
fonte

1 risposta

2

Un modulo veramente indipendente espone l'API per creare oggetti che espone e ogni oggetto esporrebbe un'interfaccia chiara a ciò che l'oggetto dovrebbe fare.

Invece di una gigantesca API da qualche parte. Ad esempio jQuery: un oggetto perché fa una cosa. jQueryUI non è un oggetto ma offre singoli oggetti come widget.

Quindi da un client (codice) di vista ciò che il modulo fa è ben documentato. I passaggi complessi per creare gli oggetti sono semplificati.

Come e quando specifichi tali dipendenze?

Il codice client dovrebbe essere solo aggiungendo il modulo come dipendenza. Se il modulo ha altre dipendenze, è necessario risolverlo quando viene risolta la dipendenza del modulo. (RequireJS, Maven Dipendenze)

Iniezione di dipendenza

Questo è diverso dalla dipendenza dal codice che hai notato. Il modello deve essere iniettato nell'interfaccia del modulo. I tuoi oggetti di servizio possono anche essere iniettati qui, ma in questo caso sono i tuoi servizi a iniettare il Modello e gli oggetti di servizio potrebbero essere creati solo da MyModuleFactory (Impl).

Il codice cliente che hai iniettato MyModuleFactory. La catena d'iniezione sarà risolta lungo il percorso.

Punto specifico Informazioni su modello e servizi - modello non anemico

I servizi possono sembrare una buona idea, ma diventa un problema su tutta la linea. Checkout casi contro questo.

Modello di dominio anemico

    
risposta data 12.08.2014 - 21:25
fonte

Leggi altre domande sui tag