Attualmente sto lavorando a un progetto MVC per un'utilità web. Questa utility accetta l'input da un utente, lo invia tramite JSON a un'API che legge da un database e riporta i dati nelle tabelle; lo fa già, e la funzionalità di base è lì.
Sto cercando di implementarlo con i sistemi attuali del mio datore di lavoro. Attualmente sto implementando un modello come questo:
View -> Controller -> Repository (prepares data) -> Client (serializes and sends data)
Tutti questi sono accessibili tramite interfaccia, quindi nessuna classe sa veramente dell'altro; solo come accedere ai metodi di esso. Sono stato contento di questo modello, specialmente con i test delle unità.
Tuttavia, si verifica un problema a livello di client: lavoriamo in più ambienti e un'API gestisce il cambiamento dinamico dell'ambiente. Per connetterci a quell'API, entriamo da un assembly comune. Quando questo assembly è stato creato, non abbiamo utilizzato il pattern del repository, quindi l'assembly comune viene creato per funzionare nel livello controller.
Ho alcuni problemi di pratica con il controller che conosce le informazioni destinate al cliente. Vale la pena notare che alcune utility nella stessa soluzione con cui sono integrato semplicemente creano il loro client nel controller, ma invalida l'uso delle interfacce e non hanno il grado di separazione aggiuntivo di un repository.
Il mio collega mi ha suggerito di seguire l'esempio e semplicemente creare il client nel controller e trasferirlo nel repository in questo modo:
View -> Controller (creates client) -[Client]> Repository
Questo eliminerebbe il refactoring, ma sono nuovo nel team e il mio tempo non è prezioso, quindi penso che varrebbe la pena per me di rifattorizzare il nostro accessor API per funzionare al di fuori del contesto di un controller.
Per coloro che hanno lavorato in contesti simili: sto pensando troppo a questo? Dal mio punto di vista, non ci giova di regredire alla pratica precedente solo a causa del codice legacy quando poteva essere refactored per funzionare con il nostro standard client-repository. Prendo atto che sarebbe più veloce per me passare semplicemente il client, ma sembra ridimensionare la maggior parte del lavoro che ho speso cercando di integrare la mia applicazione con il modello dell'interfaccia del repository.
Sono nuovo nell'ingegneria del software, quindi è molto probabile che io sia semplicemente attaccato al modo di pensare che mi è stato insegnato e non sto pensando funzionalmente.