¿NHibernate o NHibernate fluido? [cerrado]

Definitivamente diría ir con fluent-nhibernate. Solo tenga en cuenta que no necesariamente puede ser un viaje tan suave como usted esperaría.

1. Respecto a la dependencia de la versión

   1. He tenido un problema de dependencia 'inversa' al actualizar a una nueva versión de FNH me obligó a actualizar a una nueva versión de NH (2.0 a 2.1 creo). Esto no era un problema importante para mí.
   2. Hace poco (esta mañana) dejé caer NH 2.1.1 en el FNH 1.0 RTM (esto se distribuye con 2.1.0) sin dramas (todavía).

2. Editar: Desde que escribí este post FNH ha madurado sustancialmente hasta el punto en que no creo que esto sea un problema real más Compatibilidad con asignaciones - algunas asignaciones aún no son posibles con fluent nhibernate. Sin embargo, esto NO es una razón para evitar FNH, ya que las asignaciones híbridas fluent-xml le permiten recurrir al xml tradicional en caso de que fluent no pueda asignarlo (aunque esto es solo en granularidad por clase). Ejemplos de mappings:

   1. Todavía no se pueden asignar campos - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
   2. No puede mapear algunos momentos del diccionario http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - en realidad, de lo que deduzco, esta funcionalidad existe pero aún no está en la línea principal.

3. Factor de complejidad compuesto. De los sonidos de ella serás aprender FNH y NH al mismo tiempo. Para la mayoría de aplicaciones bastante simples, esto está bien: de hecho, FNH suele ser tan bueno que necesita saber bastante poco sobre hbm.asignaciones xml. Pero si quieres ir a hacer algo razonablemente compleja, rara vez la primera ronda y se preguntan si es un PEBKAC, fluidez o NH problema. Más a menudo de lo que esperaba terminé escribiendo las asignaciones xml tradicionales (por supuesto, está haciendo esto de todos modos, pero habría sido preferible no gastar más esfuerzo del necesario jugueteando con fluidez primero).

La ventaja de usar Fluent NHibernate junto con NHibernate es que obtiene errores en tiempo de compilación si ha estropeado su asignación, en lugar de errores en tiempo de ejecución. También obtiene una experiencia mucho mejor al refactorizar su código, ya que sus asignaciones se mantienen actualizadas a medida que cambia el nombre de las propiedades o lo que sea, en lugar de tener que recordar modificar manualmente los archivos de asignación XML.

El mayor inconveniente de NHibernate fluido es que todavía está en una fase bastante temprana de su desarrollo, y existe un riesgo bastante grande de romper los cambios a medida que avanza el desarrollo del marco.

Personalmente realmente no he conseguido mucho en nhibernate fluido, ya que me siento cómodo con los archivos de asignación. el uso de visual studio para crear los archivos de asignación es muy sencillo y puede establecer el esquema para el archivo xml que le proporciona intellisense en el archivo de asignación. Estoy de acuerdo en que tener una comprobación de sintaxis en tiempo de compilación es una ventaja para usar fluent-nhibernate, pero me cuesta justificar el aprendizaje de la API fluent cuando ya estoy familiarizado con la asignación XML. Tal vez debería superar mi lethergy y aprender ya... :-)

N-Hibernate fluido es realmente un buen envoltorio sobre NHibernate. Para administrar la asignación en Fluent mucho mejor que la asignación xml. El desarrollo se vuelve rápido a medida que avanza con fluidez...

Mejor si utiliza Entity Developer para crear entidad y esquema de base de datos.