¿Es tonto por mi parte no usar NHibernate para mi proyecto?

Question

Estoy trabajando en una aplicación web .NET que utiliza una base de datos SQL Server con aproximadamente 20 a 30 tablas. La mayoría de las tablas se incluirán en la solución .NET como clase. He escrito mi propia capa de acceso a datos para leer los objetos y escribirlos en la base de datos. Todo el asunto consiste en solo unas pocas clases y muy pocas líneas de código en usa genéricos y reflexión para descubrir qué SQL y parámetros usar. Ahora, tal cosa se puede hacer usando NHibernate (o framework similar) y algunos colegas afirman que es una tontería por mi parte no usarlo. Mi principal argumento para no usarlo es que quiero el máximo control sobre mi aplicación, saber exactamente qué hace todo y cómo funciona todo, incluso si eso me cuesta más tiempo de desarrollo. Tampoco me gusta el hecho de que tengo que mapear mi base de datos en archivos XML (mi propia solución me permite mapearla en los archivos de la clase de entidad).

Entonces, lo que me gustaría saber de usted es, ¿es realmente estúpido no utilizar NHibernate en esta situación? ¿Realmente estoy siendo ignorante o no es una idea tan extraña usar mi propia solución?

Answer 1

Creo que en estos días realmente no hay ninguna razón para rodar su propio marco de persistencia ya que hay tantas buenas opciones disponibles. No tiene que usar NHibernate (aunque es una buena opción) pero consideraría seriamente usar algo que esté bien probado y establecido en la industria, ya que tenderá a funcionar mejor y tendrá menos errores que algo que usted mismo escriba.

Answer 2

Probablemente es tonto para escribir sus propias clases en lugar de utilizar NHibernate, pero es menos tonto para seguir usando sus propias clases, dado que usted ya les ha escrito. Tal vez.

Answer 3

Las personas tienden a utilizar marcos que ya están escritos porque, bueno, ya están escritos (y probados).

Pero existe el mérito de rodar el suyo. Solo usted y sus colegas pueden hacer suposiciones sobre su dominio. Un marco genérico como NHibernate no puede hacer muchas suposiciones, porque eso no lo haría muy universal.

Cuando lances la tuya propia, puedes incluir estas suposiciones en tu marco, para crear una API más racionalizada y natural. Dicho esto, si comenzaras de nuevo, habría sugerido tomar un marco existente y ajustarlo para que se ajuste mejor a tus necesidades. Pero como ya tienes algo y te funciona, no estoy seguro de que sugiera cambiarlo por otra cosa.

Answer 4

Tiene muchas posibilidades que probablemente sea mejor que reinventar la rueda. Permítanme mencionar dos opciones más probables:

1. Uso Entity Framework para su DAL + DAO. Esto hará que sus clases (que ya haya escrito) sean obsoletas, ya que EF creará las suyas propias y se actualizará con las últimas capacidades y tecnologías del lenguaje.

2. Use Fluido NHibernate para que no tenga que trabajar con asignaciones de XML. De esta forma, mantendrá sus clases de objetos de capa de negocio que ha escrito y evitará tediosos archivos NHibernation XML. Es todo C#.

Su forma de pensar es buena. Quieres control Esta bien.Pero usar tu propio DAL es un poco tonto en estos días, porque básicamente estás reinventando la rueda, además no habrás probado el código con errores que tomará un tiempo considerable para desarrollar + prueba + depuración.

Si fuera usted, iría con la opción n. ° 2, ya que he hecho la opción n. ° 1 y sé que tengo que personalizar muchas cosas para que EF funcione como debería. EF estará listo con V2.

Answer 5

No te llamaré tonto porque he hecho exactamente lo mismo en el pasado. Luego comencé a usar NHibernate y me pregunté por qué diablos había hecho mi propia versión. Está bien, pruébalo.

Answer 6

Creo que es una cuestión de equilibrio de control. Usted dice que quiere control y no quiere mapeos. Si este control tiene el costo de que hay un mayor costo de desarrollo y mantenimiento y que lleva más tiempo producir código de trabajo, entonces es un problema.

Personalmente, no veo ningún problema para rodar un marco de trabajo, siempre que simplifique una tarea repetitiva y haga que el desarrollo sea más productivo y el código sea más estable debido a que hay menos espacio para la interpretación. Hemos lanzado nuestro propio marco, que incluye una implementación de persistencia/acceso a datos. Nuestras razones para hacerlo, sin embargo, fueron específicas. En este caso, era trabajar en un entorno DDD que estaba mucho más cerca de lo que describe Evans que lo que proporcionaban los productos más comunes.

Creo que la diferencia es, sin embargo, que entendimos que había un costo inicial y que finalmente se equilibraría a través de ahorros en el tiempo de desarrollo en el futuro. Por supuesto, si está escribiendo código que tiene que administrar manualmente las conexiones, los datos del mapa, etc., es probable que vaya por el camino equivocado. Como mínimo, podría estar utilizando algo como Enterprise Library para ayudarlo a administrar el tedio de la conectividad y la construcción de comandos. Pero también creo que si no tiene reutilización, nada que sea una implementación de "marco" que pueda abstraer y aplicar a otros proyectos, entonces está creando una pesadilla de mantenimiento y un sumidero de tiempo en el que será el único propietario. de.

Answer 7

Hay muchas buenas herramientas de persistencia que están bien probadas y tienen un rendimiento probado (NHibernate, Linq para entidades, LLBL Gen Pro). Si sus necesidades son muy diferentes a las de los marcos de persistencia normales que existen, entonces yo mismo lo haría. Sin embargo, me gustaría aprovechar las pruebas y optimizaciones de una herramienta existente.

Dicho esto, también podría hacer mi propio esfuerzo si quisiera tener la experiencia de construir mi propia herramienta ORM y estuve dispuesto a vivir con las desventajas (no tan probadas u optimizadas como herramientas que han existido durante años , velocidad de comercialización).

Answer 8

Hacer su propia solución, especialmente cuando parece funcionar bien y ser tan simple como usted dice, no es ni ignorante ni extraña. Hay muchas situaciones en las que es mejor hacer eso que agregar una dependencia en un proyecto separado como nHibernate.

Dicho esto, hay, por supuesto, también un montón de situaciones donde todo lo contrario es cierto. :)

Realmente depende de su proyecto y equipo. Si está desarrollando una aplicación empresarial que eventualmente será respaldada por otra persona, apegarse a los estándares de la industria puede ser una buena idea, incluso si eso significa un poco más de trabajo por adelantado.

Answer 9

Todas las respuestas aquí son geniales, pero estoy realmente sorprendido de que nadie haya mencionado Castle ActiveRecord, suena muy similar a lo que hace su estructura y realmente simplifica la interfaz de NHibernate. ¡Es uno de los patrones que hizo que Ruby on Rails fuera tan popular después de todo!

Ayende Rahien (uno de los principales desarrolladores NH) dio una gran presentación sobre ActiveRecord en Oredev hace unos años, que recomiendo encarecidamente: http://www.viddler.com/explore/oredev/videos/89

Answer 10

Nosotros también estábamos usando nuestras propias clases de capa de acceso a datos y la entidad. También teníamos un generador de código que solía generar todas estas clases para nosotros. Pero ahora estamos usando Entity Framework y estamos más que felices.

Consejo sencillo: comience a aprender nHibernate o lo que prefiera y comience a utilizarlo en su próximo proyecto.

Answer 11

Depende de lo que quieren decir con "tonto".

Si por "tonto" quieren decir que no debiste haber escrito tu capa de persistencia en primer lugar, probablemente tengan razón, pero eso es llorar por la leche derramada.

Si por "tonto" quieren decir que debe volver a escribir todo su código para usar otro marco (como NHibernate) cuando ya está trabajando con el suyo, probablemente estén equivocados (aunque hay algo que decir para # de errores en NHibernate frente al número probable de errores en el suyo).

Si por "tonto" quieren decir que todo el equipo conoce a NHibernate en frío, y ya se usa en el resto de tu código, entonces al usar tu marco lo haces más difícil en el equipo, tienen toda la razón, y probablemente deba refactorizar el código en NHibernate lo antes posible, antes de que se enganche más código en su marco.

Si por "tonto" quieren decir que nadie sabe realmente NHibernate, les gusta, entonces ... nadie gana. Están siendo quisquillosos, implementaron un marco que no tenían que ... vamos a llamarlo un empate.

Dicho todo esto, todos deberían escribir un marco de persistencia o tres. Esos probablemente no deberían terminar en nada que se envíe, pero es un buen ejercicio. El único error que cometió fue vincular el código que el equipo tenía que mantener en su buen ejercicio.

Answer 12

Espacios de entidades - http://www.entityspaces.net/Portal/Default.aspx

es también una buena herramienta.

Answer 13

Terminé usando Fluent NHibernate para el trabajo. Todas mis clases de entidad se generaron con ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)