2010-05-04 15 views
8

¿Los atributos de mapeo ofrecen la misma versatilidad que los hib de nhib hbm? ¿Puedes usarlos junto con FNH para manejar cosas que FNH aún no hace tan bien como hbm?Atributos de mapeo de NHibernate versus NHibernate con fluidez

Cheers,
Berryl

Por atributos de mapeo, no me refiero a los archivos de HBM; Aparentemente hay atributos que vienen con NHib (o quizás contribución de NHib actualmente) que usted usa para decorar las propiedades de clase de su clase &. Supongo que estos son anteriores a FNH, pero no estoy seguro.

Respuesta

5

Personalmente, prefiero crear los archivos hbm.xml. He usado Fluent, pero me gusta manejar las cosas esenciales para cosas como esta. Sin embargo, no me he encontrado con ninguna asignación que no haya podido trabajar con Fluent ...

Tengo entendido que Fluent nHibernate en realidad crea un archivo hbm.xml en segundo plano según su configuración que a su vez es utilizado por nHibernate ... siendo que Fluent mismo está creando las asignaciones, yo diría que simplemente crear el hbm.xml manualmente te daría más flexibilidad y acceso al matiz del archivo de mapeo ...

Creo que hay una curva de aprendizaje similar para ambos, así que si vas a molestarte en aprender Fluent que a su vez crea archivos hbm.xml, ¿por qué no aprendes a crear los malditos archivos hbm.xml tú mismo en primer lugar? ¡y omita al hombre del medio!

A menos que esté haciendo MUCHOS proyectos en una sucesión rápida, el hecho de mapear realmente su base de datos es solo un fragmento del trabajo real que está haciendo en un proyecto en particular.

  • Max Schilling
+0

De acuerdo. El xml-o-fóbico en mí se resistió a aprender hbm pero realmente no habrás fluido hasta que lo hagas. Estoy hablando de los atributos que son una alternativa, o fueron, tanto para archivos FNH como hbm. Cheers – Berryl

+10

Max: Entonces, ¿por qué no escribir SQL sin procesar usted mismo? Eso es todo lo que NHibernate genera al final. Es la abstracción lo que lo beneficia tanto en el caso de NHibernate como en las asignaciones de FNH. Claro, todo lo que FNH hace es generar hbms, pero también simplifica el proceso de hacerlo y le da un mayor control en un nivel superior. Estoy totalmente de acuerdo en que el mapeo es una pequeña parte del proceso de desarrollo de una aplicación, pero seguramente es mejor hacerlo una cantidad "aún más pequeña". –

+0

Creo que todo se reduce a elegir sus abstracciones. La parte de SQL es una pieza importante y nHibernate ahorra mucho tiempo en escribir SQL, pero no sé para el mapeo ... Me gusta la automatización fluida para el andamiaje rápido, pero no estoy de acuerdo con un mejor control. Si la ley de las abstracciones con fugas es cierta, y con Fluent es una abstracción de una abstracción, entonces mi preferencia es ir lo más cerca posible del enfoque de metal si es posible. Estoy tan cómodo con el hbm.xml y no los encuentro más complejos que Fluent. Es solo instrucciones diferentes para lograr el mismo resultado. –

1

Nunca me he encontrado con una situación que no pudiera ser manejada por Fluent NHibernate, pero tal vez estés usando un atributo oscuro. ¿Hay algo en particular que necesites saber está disponible?

+0

Actualmente solo uso FNH, y ni siquiera sabía acerca de los atributos de mapeo hasta leer el NHib de Manning en Acción, por lo que esta pregunta es más sobre ellos que sobre FNH. PERO una cosa que tengo problemas con FNH es que no me permite establecer los nombres y los nombres de las columnas discriminatorias (utiliza los valores predeterminados que funcionan pero no son lo que quiero). Cheers – Berryl

+1

Berryl, creo que debe plantear un problema de soporte sobre su problema discriminador porque FNH definitivamente le permite especificar tanto el nombre de la columna del discriminador como sus valores. –

+0

@James - De hecho, planteé un problema de soporte, no obtuve respuesta y vi otras publicaciones sobre el mismo problema de otros usuarios desde entonces. Véase el problema de soporte que se planteó el 26 de marzo de 2010 a las 11:07 a.m., "conversión de tabla por subclase a tabla por clase-heiraquía" (2da publicación) y este hilo http://groups.google.com/group/fluent- nhibernate/browse_thread/thread/2ece57fb14c673c5 # comenzó el 9 de marzo. Cheers – Berryl

5

atributos El NHibernate hacen son anteriores a la HNF. Aparte de un grupo relativamente pequeño de holdouts acérrimos, realmente no conozco a nadie que los use. Son compatibles, pero no son exactamente amigables. Si le gustan los atributos, los atributos Castle ActiveRecord son una implementación mucho mejor que los núcleos NHibernate.

Fluido NHibernate puede funcionar con todo lo demás. Todo lo que hace es inyectar asignaciones en la instancia de NHibernate Configuration, para que pueda poner cualquier otra cosa que desee. ActiveRecord es un poco más una solución de gran alcance, por lo que puede ser una excepción a esta regla, ha pasado un tiempo desde que lo usé.

+0

Pensé mucho. "NHib en acción" les da un tiempo de aire significativo y, por lo tanto, credibilidad, mientras dicen que FNH es un trabajo en progreso prometedor, algo que otros expertos de NHib como Ayende, Fabio y Steve Bohlen parecen decir cuando lo dicen. Si bien el libro está claramente fechado en detalles, el alcance que cubre es más sofisticado que cualquier otra cosa que haya visto hasta ahora. No sé cómo salvar mis vacíos de conocimiento más que haciendo preguntas "tontas" aquí en los foros SO y NHib/FNH. Naturaleza de la bestia IMO complicada, pero está llenando un vacío en la comunidad que muchos aprecian. Cheers – Berryl

+0

Una cosa que debes tener en cuenta es que NHibernate in Action fue publicado hace más de un año, el contenido congelado bastante antes y basado en las versiones 1.x de NHibernate. Mientras que eso no afecta la calidad de su contenido, muchos han cambiado desde entonces. –

+0

También debe tenerse en cuenta que Fluent NHibernate * nunca * admitirá todas las asignaciones posibles que NHibernate admite, ya que una gran cantidad de esas asignaciones están ahí para admitir casos extremos peculiares. Es la regla 80/20, apoyamos el 80% que las personas usan más, el resto siempre se puede hacer en hbm. –

1

Los estamos utilizando en mi negocio y me gustan un poco.

Creo que escribir el mapeo es muy sencillo directamente en la definición de la clase (lo sé, cada uno es suyo).

1

Estoy de acuerdo con la mayoría de los comentarios aquí, Hibernate le da la libertad de elección sobre cómo implementar los mapas para los objetos.

Prefiero no utilizar atributos en mis clases para NHibernate, ya que ahora mis clases tienen otra dependencia que no deberían conocer.

¿Qué ocurre si quiere cambiar su datasouce a un OODB o simplemente a un archivo? Las clases tendrán código de mapeo redundante (los atributos).en este caso, se podría decir, su limpiador para almacenar la cartografía en la capa de datos/infraestructura con la implementación de repositorios (Uso del supuesto del patrón de repositorio)

también estoy de acuerdo, cada uno para que los propios :)

+0

Estoy de acuerdo - Me preguntaba si ofrecían más "potencia" equivalente a hbm que FNH, que voy a utilizar para completar el 80% en cualquier caso. Detrás está la cuestión de qué es exactamente lo que hbms puede hacer que FNH no pueda en la actualidad. Cheers – Berryl

+0

Eso está bien, pensé que estabas considerando las asignaciones atribuidas. una cosa excelente acerca de FNH te permite convertirte en un mapa fluido en el antiguo XML, en caso de que encuentres algo que no funciona (por ejemplo, todavía tengo que encontrar algo que no puede hacer). Supongo que sabes que – dbones

1

Estoy tratando de entender dónde se encuentra NHibernate 3 en relación con Hibernate 3 con respecto a los atributos frente a la anotación. He estado en varios proyectos de Java donde usamos Hibernate 3 anotaciones para mapeo. Es bastante elegante como

  1. las ENTIDADES están claramente documentados en donde vive el código
  2. más fácil de depurar al desplazarse por el depurador ...
  3. que no tienen que ir a abrir un archivo separado de
  4. contexto
  5. menos artefactos para gestionar
  6. tiempo de compilación
  7. IntelliSense = menor número de errores tipográficos
  8. hay necesidad de instalar/aprender una tercera parte independiente componente (p. FNH)
  9. el equipo de hibernación invertido en hacer anotaciones fácil de usar e integral

No estoy seguro de comprar el "¿y si hay que cambiar las fuentes de datos" o la "separación de preocupaciones" argumentos. En la práctica, esos argumentos miran el "20%" (o menos) que, o bien no ocurrirán, o tendrán un impacto marginal si lo hacen: los beneficios son mucho mayores en mi humilde opinión.

Dicho esto, lo que no tengo claro es si el equipo de NHibernate ha invertido lo suficiente como para hacer que los atributos sean lo suficientemente robustos como para garantizar su uso, o me sería mejor cambiar a EF4.x para obtener los mismos beneficios. Estas son las respuestas que esperaba de esta publicación.

+0

FNH aún agrega mucho que los atributos no pueden manejar: 1) Automatización 2) Convenciones (para auto y manual) 3) Discoverablility (a través de una interfaz fluida) – Firo

Cuestiones relacionadas