@Component
public class RepositoryContainer {
@Autowired
public CommentRepository commentRepository;
@Autowired
public ItemRepository itemRepository;
@Autowired
public UserRepository userRepository;
@Autowired
public PostRepository postRepository;
}
In questo modo, ho solo bisogno di iniettare un singolo Dio RepositoryContainer e non ho bisogno di iniettare ogni repository che inquinerà il mio controller.
No, non dovresti. Nascondere semplicemente le dipendenze da un'altra classe di servizio non migliorerà improvvisamente il tuo controller.
Iniettare direttamente i repository nel controller è molto meglio, perché una volta che il controller cresce e si iniettano sempre più classi di servizio, la sola quantità di dipendenze iniettate da solo è un segnale di avvertimento per dirti che c'è qualcosa di sbagliato nel tuo design - forse il tuo controller sta facendo troppo.
Inoltre, RepositoryContainer inizierà anche a comportarsi come un localizzatore di servizio , che non è molto buono .
Iniettando i repository direttamente nel tuo controller, stai rimuovendo un livello importante - Service layer, che è pensato per fare tutto il lavoro pesante nella tua applicazione.
Sono d'accordo con la risposta di David Packer in una certa misura che il tuo controller dovrebbe rimanere pulito senza troppo codice che non ha nulla a che fare con le chiamate di routing, tuttavia non salterò il livello di servizio.
Scollega il livello Web dal livello dao se in qualsiasi momento in futuro si desidera modificare l'implementazione del database.
Vorrei andare per UserService , ItemService , PostService e chiamarli dal controller e farli gestire la logica per ciascun dominio separatamente.
Leggi altre domande sui tag architecture design-patterns repository spring dao