¿Hay alguna trampa o buenas razones para no usar autosproc para llamadas a procedimientos almacenados?
-
06-07-2019 - |
Pregunta
Implementé una capa de acceso a datos que llena entidades genéricas de un lector de datos utilizando una variación del tercer enfoque de mono ( http://www.codeproject.com/KB/database/DynamicMethod_ILGenerator.aspx ). Esto funciona bien, funciona bien y me ahorra escribir un montón de código repetitivo para la recuperación de datos.
Ahora quiero agregar métodos que toman una entidad genérica y convertirla en una lista de parámetros para alimentar a un proceso almacenado para poder agregar persistencia de datos a la colección de trucos de mi mono.
Encontré algunas pautas en: http://msdn.microsoft.com /en-us/library/ms973259.aspx y algunos códigos de muestra en la solución de autosproc. Se ve bien en el papel y tengo la intención de incorporar esto, pero un google rápido no apareció mucho en la experiencia del usuario de implementar autosproc y estoy buscando un pulgar hacia arriba (o hacia abajo) de cualquiera que haya estado allí y lo haya hecho ya.
Entonces, ¿has usado autosproc? ¿Funcionó bien para ti? ¿Hay alguna falla en el rendimiento o en otro lugar que la haga inadecuada en una aplicación empresarial?
Consejos apreciados.
Solución
Creo que es más fácil remitirlo a esta pregunta, donde mi respuesta contiene enlaces a su cosa de AutoSproc: TSQL - Plan de ejecución de análisis para determinar las columnas que serán devueltas por un procedimiento almacenado
Para resumir, no me gustó: causó demasiados problemas.
(Solo hurgando en preguntas sin respuesta y encontré esta)