Me interesaría escuchar las opiniones de otros acerca de si elegirían (no 'neithers' por favor;), y por qué.NHibernate o Fluidez NHibernate?
¿Cuáles son las desventajas de usar con fluidez? (¿dependencia de la versión tal vez?) Pros, contras, Experiencias, etc.
Fluido NHInarnate se sienta encima de NHibernate, por lo que no es realmente una elección entre los dos. Si vas a utilizar NHibernate, ELIJA usar Fluent NH encima para ahorrar grandes cantidades de esfuerzo.
Fluido NHibernate es increíble, no usaría NHibernate sin él. Puedes mapear con fluidez todas tus entidades (brindándote chequeo en tiempo de compilación y soporte automatizado de prueba) en lugar de tener que mantener engorrosos archivos xml y recordar su sintaxis/DTD.
También puede asignar automáticamente sus entidades en función de sus convenciones personalizadas y/o predeterminadas.
¡Solo conócela!
Sí, lo siento, debería haber expresado mi pregunta de forma ligeramente diferente;) Gracias por la respuesta. – UpTheCreek
Sí, no podría estar más de acuerdo. Hemos utilizado Fluent junto a las bibliotecas de Rhino y Geo. ¡De vez en cuando nos encontramos con discrepancias de versiones! – Perhentian
Yo en segundo lugar. Acabo de empezar a usar Fluent NHibernate, y no lo hago (no lo haré). Es increíble lo fácil que es mapear tus clases. – Siewers
La ventaja de utilizar Fluent NHibernate junto con NHibernate es que usted obtiene errores de tiempo de compilación si ha estropeado su mapeo, en lugar de errores de tiempo de ejecución. También obtiene una experiencia mucho mejor cuando refactoriza 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 acordarse de modificar manualmente sus archivos XML de mapeo.
El mayor inconveniente de Fluent NHibernate es que todavía se encuentra 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.
En mi experiencia, la mayoría de los errores debidos a malas asignaciones que encuentro usando FluentNHibernate ocurren en tiempo de ejecución, cuando NHibernate se usa por primera vez en la aplicación. Solo refactorización simple/tipos de desajustes/errores de ortografía/etc. causará errores de tiempo de compilación. –
Personalmente, realmente no he conseguido mucho en nhibernate con fluidez ya que me siento cómodo con los archivos de mapeo. El uso de Visual Studio para crear los archivos de mapeo es muy simple y puede establecer el esquema para el archivo xml que le da intellisense en el archivo de mapeo. Estoy de acuerdo en que tener la verificación de la sintaxis en tiempo de compilación es una ventaja para usar fluent-nhibernate, pero me cuesta justificar el aprendizaje de la API fluida cuando ya estoy familiarizado con el mapeo XML. Tal vez debería superar mi lethergy y aprenderlo ya ... :-)
Definitivamente diría que vaya con fluent-nhibernate. Solo ten en cuenta que no necesariamente es un viaje tan fácil como esperas.
En cuanto a la dependencia de la versión
Editar: Después de haber escrito este post FNH ha madurado considerablemente hasta el punto que no creo que esto es un verdadero problema más
apoyo Mapping - algunas asignaciones todavía no son posibles con nhibernate fluidez. Sin embargo, esta 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 no pueda mapearlo con fluidez (aunque esto solo se aplica a la granularidad por clase).Los ejemplos de asignaciones:
Compuesto factor de complejidad. A partir de los sonidos, aprenderá tanto FNH como NH al mismo tiempo. Para la mayoría de las aplicaciones bastante simples, esto está bien; de hecho, FNH es a menudo tan bueno que necesitas saber bastante poco sobre las asignaciones de hbm.xml. Pero si quiere hacer algo razonablemente complejo, rara vez funcionará la primera vez y se preguntará si se trata de un problema de PEBKAC, fluido o NH. Con más frecuencia de lo que esperaba, terminé escribiendo las asignaciones de xml tradicionales (por supuesto, usted está haciendo esto de todos modos, pero hubiera sido preferible no gastar más esfuerzo de lo necesario jugando primero con fluidez).
Gracias por tus pensamientos - Te escucho en el punto 3. Al final fui con FNH, pero también estoy haciendo un pequeño proyecto sin fluidez - Esta fue una muy buena idea, ya que siento que estoy aprendiendo mucho sobre NH y sentirse más cómodo sabiendo realmente lo que está pasando. (Por cierto, tuve que buscar PEBKAC, pero sí, aquí es de donde provienen la mayoría de mis problemas;) – UpTheCreek
Solo para su información, los campos ahora son compatibles con la última versión. –
siempre puede generar el hbm.xml a partir de las asignaciones fluidas y editarlas a mano. No es necesario escribir todo a mano. – Firo
Fluent N-Hibernate es realmente una buena envoltura sobre NHibernate. Para administrar el mapeo en Fluent es mucho mejor que el mapeo xml. El desarrollo se hace más rápido a medida que avanza a Fluent ...
Es mejor si utiliza Entity Developer para crear la entidad y el esquema de la base de datos.
El archivo hbm.xml se utiliza en NHibernate para el mapeo, pero Fluiber NHibernate lo reemplaza en el código C#. Es muy fácil encontrar un problema y mantenerlo. –
Pregunto esto hace más de 3 años, ¿y se cierra este mes? ¿eh? – UpTheCreek