Contesto delle applicazioni di primavera: caos delle dipendenze

0

Sono nuovo in un team che lavora su un'applicazione Spring MVC sviluppata e complessa. Il contesto dell'applicazione è ampiamente cablato utilizzando i costruttori annotati da @Autowire. Questo sembra essere il motivo principale del problema che vedo con l'applicazione: non esiste una struttura globale dell'applicazione. Se qualcuno che implementa un bean A ha bisogno di una feature di un altro bean B, aggiunge questo altro bean al costruttore di A, indipendentemente dal pacchetto di B o dalla categroy di B. Se qualsiasi bean A (lascia che sia un semplice helper ) richiede dati di sessione, HttpSession viene iniettato (ovviamente un proxy di sessione). Invece di passare gli oggetti del dominio agli oggetti helper tramite gli argomenti del metodo, l'helper ottiene l'accesso a un servizio per recuperare i dati del dominio da solo. Nel corso del tempo ciò ha portato a un'enorme rete di dipendenze. Ho persino visto implementazioni di comparatori basate sui servizi di Spring. Non è possibile individuare alcun livello o livello o modulo o gerarchia nell'applicazione come (controller / servizi / accesso dati).

Sono convinto che questa non sia una buona architettura, ma i sentimenti istintivi non sono sufficienti per convincere la mia squadra che c'è un problema con questa applicazione. Potrebbe anche rivelarsi che tutto va bene e il mio istinto dovrebbe stare zitto ;-) Ho provato a cercare sul web eventuali anti-pattern di applicazione Spring ma non sono riuscito a trovare fatti di supporto. Quindi le mie domande:

  • Questo problema è noto come anti-pattern per le applicazioni Spring che esprime le mie preoccupazioni? Come ho detto, sospetto che la convenienza di @Autowire sia la ragione principale. È troppo facile far dipendere un bean da un altro.
  • Conosce un libro / articolo incentrato sulle migliori pratiche per l'architettura dell'applicazione Spring? La maggior parte delle cose su Spring si concentra sui dettagli tecnici, non tanto su come progettare l'architettura sonora.
  • Quali problemi otterremo continuando come descritto?
posta rainer198 20.03.2018 - 11:08
fonte

2 risposte

2

Come al solito, tutto può essere abusato in qualche modo. @Autowired non è la causa della tua complessità. È semplicemente un modo efficace per iniettare un altro oggetto. Ne più ne meno.

A quanto pare, il tuo mal di testa deriva dal fatto che tutti i tipi di oggetti sono iniettati dappertutto. Anche se non usano @Autowired ma invece fabbriche / inizializzatori o qualsiasi altra cosa, la struttura globale e il caos delle dipendenze non sarebbero diversi, aggiungerebbe solo un livello di complessità in cima.

Forse alcuni semplici refactoring aiuterebbero, tentando di fornire livelli identificati migliori ed estraendo blocchi di codice in librerie separate.

    
risposta data 20.03.2018 - 14:39
fonte
1

Ho lavorato in diverse app Spring / DI e in molti casi le ho viste diventare più complesse del necessario a causa delle persone che usano DI senza pensare prima, se necessario.

Mentre un "budello allenato" può spesso indirizzarti nella giusta direzione se qualcosa è un odore o no, trovo che un buon approccio è usare esempi concreti. Una tecnica comune che uso è testabilità; quale impatto ha (presunto uso eccessivo) di DI rispetto alla testabilità di una classe? L'unità verifica solo dichiarazioni di Mockito? Devi costruire risme di contesti di applicazione web di Spring per testare una piccola unità di codice? Come sarebbe se fosse progettato in modo diverso?

Un'altra idea potrebbe essere quella di prendere una classe colpita da questo problema e rifattorizzarla per utilizzare un approccio diverso, quindi confrontare e confrontare gli approcci con i tuoi compagni di squadra. Gli esempi pratici superano sempre argomenti teorici / filosofici, nella mia esperienza.

    
risposta data 21.03.2018 - 02:11
fonte

Leggi altre domande sui tag