Ci sono problemi o buoni motivi per non utilizzare l'autosproc per le chiamate alle procedure memorizzate?

Question

Ho implementato un livello di accesso ai dati che popola entità generiche da un cacciatore di dati usando una variante del terzo approccio scimmia ( http://www.codeproject.com/KB/database/DynamicMethod_ILGenerator.aspx ). Funziona bene, funziona bene e mi fa risparmiare un sacco di codice ripetitivo per il recupero dei dati.

Ora voglio aggiungere metodi che prendono un'entità generica e la convertono in un elenco di parametri per l'alimentazione in un proc memorizzato in modo da poter aggiungere la persistenza dei dati alla raccolta di trucchi della mia scimmia.

Ho trovato alcune indicazioni su: http://msdn.microsoft.com /en-us/library/ms973259.aspx e del codice di esempio nella soluzione autosproc. Sembra buono sulla carta e ho intenzione di incorporarlo, ma un rapido google non ha mostrato molto in termini di esperienze degli utenti nell'implementazione di autosproc e sto cercando un pollice in alto (o in basso) da chiunque sia stato lì e lo abbia fatto già.

Quindi, hai usato autosproc? Ha funzionato bene per te? Ci sono difetti spalancati nelle prestazioni o altrove che lo renderebbero inadatto in un'applicazione enterprise?

Consiglio apprezzato.

Answer 1

Penso che sia più semplice rimandarti a questa domanda, in cui la mia risposta contiene collegamenti alla tua cosa AutoSproc: TSQL - Piano di esecuzione di analisi per determinare le colonne da restituire mediante una procedura memorizzata

Per riassumere, non mi è piaciuto: ha causato troppi problemi.

(Cercando solo domande senza risposta e ho trovato questa)