Chiamando il servizio e il livello del repository dal controller

Se il livello del repository è correttamente estratto (ad esempio, il livello di servizio e il controller possono accedere al repository solo tramite interfacce), quindi:

1. Avere il controller per accedere al repository semplifica direttamente quella parte del codice quando rimuove un livello di astrazione non necessario, ma
2. Quindi accoppi i controller a entrambi i livelli di servizio e repository, che possono aumentare la complessità e
3. È possibile che si stia creando un problema di manutenzione nel caso in cui sia necessario aggiungere la business logic in quel punto in futuro e quindi "re-scandagliare" quella parte del codice, ma
4. Il principio YAGNI ("Non hai bisogno di gunna") entra in gioco qui, quindi è improbabile che tu possa consentire a questi potenziali problemi futuri di influenzare il design ora.

A conti fatti, continuerei a nutrire tutto attraverso il livello di servizio. Ma questa è pura opinione; l'accesso diretto al repository è ugualmente valido.

Se il livello del repository non è correttamente astratto (ovvero il livello di servizio tratta direttamente con le classi concreta di repository / database), allora:

1. Risolvi!
2. Non lasciare che i controller si avvicinino al repository finché non lo risolvi, poiché questo percorso porta a testare l'inferno.

Le dipendenze richieste per le classi del repository non dovrebbero essere necessarie per le classi del controllore. Se non ti dispiace avere le dipendenze lì, suppongo che potresti saltare la chiamata pass-through e andare direttamente al repository.

Si riduce a fare in modo che il controller ora abbia una dipendenza dai repository.

Ho presunto che i tuoi repository siano un'astrazione sopra l'archivio dati effettivo e non stai chiamando direttamente in un database o un file system o cosa hai.

È meglio essere coerenti e chiamare sempre il livello di servizio anche come passaggio. La coerenza è più importante rispetto al salvataggio di poche righe di codice non interessante. Ciò consente di aggiungere potenziali logiche di business per adattarsi alle future modifiche e può aiutare a fungere da segnale per non separare la logica aziendale quanto si dovrebbe se si dispone di molti metodi vuoti nel livello di servizio.

Gran parte del fatto di essere in grado di mantenere un progetto è che ci sono pochissime / nessuna aree che si comportano inaspettatamente e non seguono gli stessi schemi.