UI richiede i dati di determinati tipi. Può andare in un SPROC?

La creazione di un SP (o meglio di una vista) che restituisce un sottoinsieme di dati da una tabella è praticabile, ma sovraccaricare l'SP con un flag per consentirne l'utilizzo in un modo diverso non è una buona opzione. Le decisioni chiave ruotano attorno alla decisione su dove dovrebbe esistere la logica di business per filtrare i dati restituiti; e soppesando i compromessi tra riutilizzo del codice, leggibilità e manutenibilità. La cosa peggiore che si può fare è duplicare la logica in entrambe le posizioni, perché ciò rende difficile la manutenzione e la risoluzione dei problemi quando le regole non vengono sincronizzate, cosa che inevitabilmente faranno. Traccerò quattro opzioni generali, sebbene ce ne siano sicuramente altre.

1. Ad un estremo, lasci che tutta la logica viva nel database (che suona come i tuoi amministratori di database) e faccia chiamate e recuperi i dati attraverso SPROC specifici del programma. Dovrebbe rendere più semplice il tuo lavoro come sviluppatore dell'interfaccia utente, dato che puoi ignorare lo schema sottostante e trattare gli SPROC come un'API per i dati. Ricorda che il DBA richiede lo stesso insieme di buoni requisiti e criteri di accettazione necessari per il successo. Il lato negativo di questo è che è possibile superare gli SPROC se il database deve supportare più sistemi con esigenze diverse. Microsoft SQL Server ha introdotto Schemas come parte di SQL Server 2005 per aiutare a gestirlo, ma è ancora una complessità aggiuntiva. Ogni interfaccia utente è strettamente collegata al proprio insieme di stored procedure, pertanto la distribuzione delle modifiche non è un problema in quanto gli SPROC sono isolati l'uno dall'altro (da schema o convenzione di denominazione).

2. Nel mezzo, è possibile creare SPROC generici che restituiscono tutti i dati di un determinato tipo e filtrano nel programma di consumo. Questo è il più sicuro, poiché mantiene la logica del filtro isolata nei programmi che ne hanno bisogno e riduce la maggior parte delle procedure a semplici istruzioni di selezione con join e senza parametri. L'utilizzo dei nomi di colonna anziché degli indici ordinali per accedere ai dati nei risultati può anche isolare in qualche modo i programmi dalle modifiche dello schema nei risultati restituiti. Il lato negativo qui (come hai notato sopra) è che vengono restituiti dati aggiuntivi per ogni chiamata, il che può influire sulle prestazioni.

3. Un'altra opzione intermedia è la creazione di SPROC più complessi che contengono parametri che aiutano a filtrare i dati. Le procedure memorizzate in questo caso possono diventare piuttosto complesse. Inoltre, l'accoppiamento tra front-end e database può causare problemi di distribuzione e di manutenzione, soprattutto se è necessario modificare l'elenco dei parametri su una stored procedure condivisa e tutti i programmi dipendenti non sono su una pianificazione di rilascio sincronizzata.

4. All'altro estremo, puoi lasciare tutta la logica in diretta sopra il database e utilizzare un ORM per gestire tutti gli accessi ai dati sottostanti. Se sei interessato ad usare Linq in SQL come ORM, guarda link e vedere come stanno passando un elenco di valori in un metodo. È possibile passare facilmente un elenco di stati dall'interfaccia utente a un metodo e consentire a Linq di creare SQL appropriato per l'utente. Pensa alle responsabilità dei tuoi tier e non temere di avere metodi helper che chiamano GetPaymentList con gli elenchi di stato appropriati per nascondere tale complessità.

Il mio ordine di preferenza è 1, 4, 2, 3. Se (come dichiari in un commento) sei costretto a SPROC dai tuoi DBA, ti suggerirei di andare con la prima opzione e di costruire SPROC specifici per la tua applicazione. Ciò presuppone che tu abbia o gli amministratori di database che scrivono le procedure memorizzate per te o che tu abbia talento SQL nel tuo team. Se nessuna delle due ipotesi è valida, tornare alla prima via di mezzo con SPROC generici e filtrare nell'interfaccia utente. La terza opzione (cercare di costruire un insieme flessibile di stored procedure che possano funzionare per un eventuale utilizzo futuro) è l'over-engineering. Piuttosto che risolvere un problema che non esiste ancora, preferirei vederti passare quel tempo in più costruendo un buon set di test di regressione per il codice / interfaccia in modo da poterlo rifattorizzare con sicurezza quando il problema (o qualche altro requisito ) sorge.

La quarta opzione non funzionerà per te a causa del requisito DBA, ma è anche un'alternativa molto valida per l'uso in un ambiente diverso.