Cosa significa "avvolgere" una stored procedure?

-2

Il mio manager mi ha chiesto di "solo avvolgere la stored procedure".

I requisiti sono di creare un microservizio che farà quanto segue:

  1. Accetta i parametri dall'utente.
  2. Passa questi parametri alla stored procedure.
  3. Ritorna al client il set di risultati della stored procedure.

All'inizio della mia carriera questo era sicuramente il mio approccio: accoppiando strettamente tutto, hardcoding, senza astrazioni, ecc.

I requisiti che mi sono stati dati, sono di fare proprio questo.

È possibile accoppiare saldamente diversi livelli, mantenendo comunque un livello di astrazione?

Per dare un po 'più di contesto, il flusso è il seguente:

Accetta l'input dell'utente tramite un ApiController:

public class MyController : ApiController
{
     public ResponseObject Get ( RequestObject request )
     {
       string sql = GenerateSql(request);
       ResponseObject response = ExecuteSql (sql);
       return response;
     }
}

Che cosa è strettamente associato qui?

  1. Se la stored procedure cambia, allora il RequestObject deve cambiare.
  2. Se la stored procedure cambia, quindi ResponseObject deve cambiare.
  3. Se la stored procedure cambia, allora la logica GenerateSql dovrà essere modificata.
  4. etc

Posso ancora implementare un design robusto qui, dato che i vincoli temporali riflettono che tutto deve essere hard-coded?

    
posta l--''''''---------'''''''''''' 15.11.2017 - 16:45
fonte

2 risposte

4

Sembra che si sia arrivati a questo: il tuo manager è soddisfatto del livello di astrazione fornito dalla stored procedure in questione. Quello che vuole non è in realtà un altro livello in sé - è solo un'altra parte dello stesso livello, fornendo un'interfaccia sintatticamente diversa. La domanda su strati strettamente accoppiati sarebbe rilevante solo se questo fosse davvero un altro livello.

La tua domanda sembra fondata sull'idea che un altro livello che fornisce un livello più alto di astrazione sia davvero necessario. Senza sapere qualcosa sul codice in questione, tutto ciò che posso fare è prendere una ipotesi approssimativa basata sul livello di astrazione fornito dalla maggior parte delle altre stored procedure che ho visto. Sulla base di questo, sarei tendenzialmente d'accordo sul fatto che un livello più alto di astrazione è probabilmente utile e utile (ma dubito che qualcuno possa rendere una dichiarazione molto più strong di quella senza ulteriori informazioni sulla situazione attuale).

D'altra parte, dovrei dire che in principio (se solo raramente nella pratica), non c'è necessariamente nulla di terribilmente sbagliato nell'idea di base di fare una traduzione sintattica di base senza tentare per fornire un livello più alto di astrazione. Almeno in teoria, la richiesta del tuo capo potrebbe essere perfettamente ragionevole.

    
risposta data 16.11.2017 - 00:48
fonte
2

Non è una buona idea assemblare l'SQL nel codice. Aumenta la superficie di attacco per gli attacchi di iniezione e avrà prestazioni più lente (in particolare CPU) a causa della compilazione dell'istruzione SQL ogni volta.

Se si desidera collegare la chiamata della procedura memorizzata all'oggetto richiesta, suggerisco di impostare un componente nel processo di compilazione che emetta uno script di distribuzione SQL basato sull'ultima implementazione della richiesta, quindi distribuire le stored procedure insieme al codice . In questo modo saranno sempre sincronizzati.

Oppure potresti usare un approccio code-first; Entity Framework genererà e distribuirà le stored procedure per te .

    
risposta data 15.11.2017 - 23:59
fonte

Leggi altre domande sui tag