Procedure moderne per applicazioni basate su stored procedure

3

Lavoro in una soluzione abbastanza grande e vecchia che ha molti punti di accesso per diversi tipi di client, con siti Web per l'accesso pubblico, siti Web per l'accesso interno, alcuni siti Web e servizi Web per l'accesso delle aziende partner, ecc.

Tutte queste applicazioni utilizzano tecnologie diverse (basate su Microsoft), come ASP classico, WebForm ASP.NET, MVC 3, ASMX, DTSX, ecc. Il codice non ha uno standard e molti programmatori senza esperienza su base di codice e nel business hanno codificato a modo loro.

Il punto centrale di tutte le applicazioni è un database SQL Server con tonnellate di stored procedure che implementano tutte le regole aziendali. Le applicazioni sono in genere solo una shell per il database. L'accesso ai dati avviene senza framework o ORM (usando puro ADO.NET, riscrivendo normalmente tutto dalla creazione di una connessione per iterare attraverso un lettore di dati su ogni metodo, funzione o qualsiasi altra cosa).

Quali sono le best practice più moderne per creare uno strato di accesso ai dati produttivo basato su stored procedure?

Per motivi di lavoro, non possiamo riscrivere le vecchie applicazioni (il cliente non pagherà per questo, e il volume del lavoro giornaliero è troppo grande per farlo internamente). Inoltre, non possiamo utilizzare alcun ORM di terze parti (gli architetti sono contrari per "motivi di sicurezza"). Quindi, i miglioramenti devono essere più simili ai refactoring.

    
posta Raphael 24.07.2013 - 17:06
fonte

1 risposta

8

Ah, la classica "procedura memorizzata delle regole aziendali 1000 righe, nessun test unitario, applicazione palla di fango".

Consente modifiche alla produzione perché è sufficiente accedere al server SQL e aggiornare un po 'di codice SQL e non è necessario ridistribuire l'app.

In pratica, il mio consiglio è di smettere di mettere per la prima volta le nuove regole aziendali delle funzionalità nel livello stored procedure.

Qualsiasi cosa tu stia scrivendo da zero che accede al database e supponendo che tu non possa usare gli strumenti ORM, metti il tuo CRUD SQL in stored procedure. Mantieni le tue regole aziendali nel codice e assicurati che sia stato testato unitamente.

Non è necessario utilizzare gli strumenti ORM per raggiungere questo obiettivo (anche se la scusa dei "motivi di sicurezza" mi sembra simile a BS)

Se hai più applicazioni che accedono a un database comune, potresti voler introdurre un livello di servizio comune, per fornire funzionalità comuni a più applicazioni in modo coerente.

    
risposta data 24.07.2013 - 17:16
fonte