Me atrevo a decir que utilizar procedimientos almacenados para operaciones CRUD simples no es que te de poco rendimiento, pero si poca mantenibilidad.
La ventaja de utilizar un ORM es que tu aplicación se basa en el modelo lógico de entidades. Si trabajamos orientados a objetos, qué mejor que todo sean objetos?. Tu aplicación trabajará con dichos objetos y será lo que se llama "persistence ignorance". Por otro lado, el uso de un ORM facilita enormemente el desarrollo, ya que los programadores no tienen necesidad de conocer todos los detalles del modelo de datos. Trabajar con clases es muy fácil. Hacer el new, establecer propiedades y decirle a NH que grabe. Otro elemento a tener en cuenta es que muchas veces, se realizan actualizaciones de versiones de bases de datos. Dichas actualizaciones no deben afectar a la aplicación con NH, ya que el "dialect" se encarga de convertir los objetos en sentencias SQL para la base de datos que sea. Podría hablarte de que con SP la concurrencia te la trabajas tú y además tienes que trabajar a "bajo nivel", lo que te lleva a tener que programar su capa de datos y demás. Hazte a la idea de los temas que se pueden plantear... En el caso de procesos de base de datos que pueden ser costosos porque hay toda una lógica implementable en PL o T-SQL, como puede ser traspaso de datos entre tablas, snapshots para reports, etc yo soy partidario del uso de SP. Pero utilizar SP para gestionar entidades da lugar a que, en una base de datos con 100 tablas, puedes acabar teniendo 400 SP's... y a ver quien mantiene eso... Si cambias una tabla agregando un campo, usando SP's tendrás que modificar los SP's y tu código para pasar el valor del nuevo campo, agregando los cambios de tu lógica de negocio... Si cambias la tabla agregando un campo y utilizas NH, deberás agregar simplemente la propiedad relacionada con ese campo y el mapping (y rellenar ese dato donde sea...) Es mucho más localizable, como puedes imaginar. Te comento que he trabajado con bases de datos de más de 500 tablas. No me imagino tener 500*4 = 2000 procedimientos... que miedo... y la capa de datos y/o BL enorme... Y muuuucho más :) On 28 sep, 15:27, Shaka <[email protected]> wrote: > agradezco la respuesta de todos, estoy tratando de mostrar esta > alternativa tomando en cuenta cuando es que realmente vale la pena > utilizar stored procedures, y no usarlos a diestra y siniestra para > insert simples por ejemplo, es magnifico este foro saludos > > El 28/09/09, Carlos Peix <[email protected]> escribió: > > > > > Hola Shake, > > Seria mas facil responderte (y para vos convencer) si conocieramos los > > motivos detras de la "mentalidad" que mencionas. > > > Muchos de los motivos simplemente no tienen fundamento, otros si. > > > En caso de que los motivos que expongan no tengan fundamento, te ayudamos a > > rebatirlos. En caso de que sean de los motivos que si tienen fundamentos, > > podes trasladar la decision de la sobrecarga de trabajo que implica usar > > SPs, que no es mayor que la que implica para otras implementaciones, pero > > como el resto de las cosas es tan sencilla con NH, escribir y mantener SPs > > se convierte, relativamente, en una sobrecarga importante. > > > Un saludo > > > ---------------------------------- > > Carlos Peix > > > 2009/9/21 Shaka <[email protected]> > > >> Buenas tardes, recien comienzo con NHibernate la vdd es que me parecio > >> preciosa la implementación me encanto, solo que en donde trabajo la > >> mentalidad es usar stored procedures podrian ayudarme a mostrar > >> argumentos para cambiarlo o mostrarme el beneficio de usarlos desde > >> nhibernate, muchisimas gracias por una herramienta como esta. --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
