Oggetto richiesta API con il metodo Handle ()

0

Questo è un vero codice di produzione, e penso che ciò che ho spogliato sia davvero irrilevante per la domanda. (Se ho torto sono sicuro che verrò corretto.)

Questo è un oggetto richiesta ricevuto da un'applicazione API Web .NET. La nostra applicazione ne ha dozzine e ognuna ha un metodo Handle() .

Non sono lo sviluppatore di API Web più esperto, ma a me sembra non funzionare. Mi sembra che un controller debba gestire una richiesta o delegarla a un orchestratore, ma per una richiesta di "gestione" stessa sembra una chiara violazione dell'SRP. Sembra anche strano iniettare le dipendenze in una classe che dovrebbe essere solo un contenitore per i dati.

Questo è per la mia comprensione. Non sto chiedendo a nessuno di risolvere una discussione. Il consulente che ha scritto questo è andato avanti. Lo sono anch'io. Ha detto che questo era il "nuovo paradigma" per la scrittura di API Web. Sto solo cercando di capire - mi sto perdendo qualcosa, o è questo un modello comune per lo sviluppo di API Web?

Grazie

public class GetUserRequest 
{

    IUserRepository _userRepository;
    IActiveDirectoryRepository _activeDirectoryRepository;
    IMapper _mapper;
    IAccountRepository _accountRepository;

    public GetUserRequest(IUserRepository userRepository, IMapper mapper, IAccountRepository accountRepository, IActiveDirectoryRepository activeDirectoryRepository)
    {
        _userRepository = userRepository;
        _mapper = mapper;
        _accountRepository = accountRepository;
        _activeDirectoryRepository = activeDirectoryRepository;
    }

    public async Task<UserApiModel> Handle()
    {
       ...
    }
}
    
posta Scott Hannen 11.08.2017 - 17:46
fonte

1 risposta

1

Non so cosa intende per "nuovo paradigma". Intende in-house o pratica comune? Perché non penso che sia una pratica comune.

La cosa tipica che vedresti è

service.Handle(IRequest request);

Ma in alcuni casi, per gestire la richiesta, il servizio ha bisogno di accedere a variabili private, in modo da poterlo invertire, con l'aiuto di una dipendenza che viene iniettata nel metodo (e non la classe), in questo modo:

request.Handle(IService service);

... che consente alla richiesta di gestire qualsiasi trasferimento di dati, possibilmente copiando variabili private in parametri nel metodo di servizio. Questo normalmente sarebbe abbastanza leggero, per esempio

class Request
{
    public void Handle(IService service)
    {
        service.doSomething(_somePrivateField, _someOtherField);
    }
}

... in modo che la vera logica rimanga nel servizio. È un po 'troppo breve, ma questo genere di cose in realtà non viola l'SRP perché è ancora il servizio che sa come elaborare i dati; la richiesta è solo responsabile per l'archiviazione e il trasferimento dei dati. Non irragionevole.

Ma questo?

var request = new Request(IService service, IOther other, etc.)
request.Handle();

... mi sembra molto insolito. Dovresti essere in grado di creare un'istanza di una richiesta e lavorarci sopra senza creare un'istanza e passare una tonnellata di dipendenze, perché è molto probabile che non finirai per inviare la richiesta, ad es. se non supera la convalida.

Suppongo che se la richiesta abbia anche la responsabilità di convalidare se stessa, e ha bisogno del servizio e di altre dipendenze per farlo (es. AddUserRequest potrebbe aver bisogno di sapere come verificare se un utente con lo stesso nome utente già esiste), allora forse dovresti farlo in questo modo. Personalmente non ... quel tipo di convalida si svolgerà nel livello aziendale o nel livello dati. Sembra gonfiare il grafico delle dipendenze e piegare le regole quando si tratta di SRP. A mio modesto parere.

Scusa se non ho una risposta solida (sembra che questo genere di cose sia simile a modello di dominio ricco contro il dominio anemico , che non è stato risolto) ma spero che questa risposta aiuti.

    
risposta data 11.08.2017 - 23:15
fonte

Leggi altre domande sui tag