NHibernate architecture?

Question

Planeo implementar mi próximo proyecto (asp.net MVC) utilizando nhibernate como ORM. Como no tengo experiencia con nhibernate, me pregunto cómo debería organizar las dependencias entre los diferentes proyectos. que he visto algo así como un enfoque recomendado:

• interfaz de usuario depende del modelo, repositorios y NHibernate
• repositorios dependen del modelo y de Nhibernate

 

    ----- UI----------------------------- 
    |    |     | 
    |    |     | 
    Model NHibernate 

El problema es que hago No quiero que el código UI interactúe directamente con nhibernate, entonces estoy pensando en algo como esto:

• interfaz de usuario depende del modelo y de la fachada
• Fachada depende del modelo y de Nhibernate

----- -------- IU | | | | Modelo

Fachada, en realidad tendrá los repositorios y encapsulará los objetos nhibernate.

¿Suena razonable? ¿Hay alguna guía sobre la arquitectura preferida?

Gracias

Answer 1

Esto es generalmente lo que hago en mis aplicaciones:

• Foo.Core

  • contiene objetos de dominio, la lógica de negocio, etc.
  • ninguna referencia a los ensamblados relacionados con la infraestructura, tales como servicios web, ESB, o acceso a datos
  • algunas personas también ponen interfaces de repositorio aquí, pero eso es una elección de diseño. Se le permite tener sus servicios de dominio aquí, que interactúan con los repositorios, siendo desacoplada de NHibernate

• Foo.Persistence

  • referencias a NHibernate
  • implementaciones del repositorio
  • unidad de trabajo HttpModule para ASP.NET (ayuda a controlar el ciclo de vida de la sesión de NHibernate en una aplicación web)

• Foo.Web

  • referencia tanto Foo.Core y Foo.Persistence
  • HttpModule referencia a controlar la sesión de NHibernate

Foo.Web no interactúa con NHibernate directamente ... siempre es a través de los repositorios. Con un contenedor IoC, solo puede solicitar IRepository y no le importa cuál es la implementación.

Answer 2

Catharsis podría tener lo que busca.

Answer 3

Yep. Eso suena bien. Nunca utilicé NHibernate, pero tener tu modelo compartido entre tu interfaz de usuario y una fachada suena bien. Por supuesto, hay muchas maneras diferentes de alcanzar los mismos objetivos, pero el suyo se ve bien. :)

Answer 4

Ha declarado que planea usar el patrón MVC. Esto implica que su UI no interactuará con el nivel de datos (en su caso, NHibernate). Lo que interactuará con el nivel de datos es su nivel de negocio, y su UI interactuará con su nivel de negocio.

No estoy familiarizado con ASP.NET, por lo que no puedo aconsejarle sobre una estructura precompilada para esto, pero en Java, que es lo que uso principalmente, tendría sus EJBs aislar su UI de el nivel de datos haciendo todas esas llamadas a través de los EJB.

Piensa en aislar el código para cada nivel. Usted tiene un recuadro para cada nivel, y cada recuadro solo puede comunicarse con un recuadro debajo del mismo a través de canales específicos. Entonces su nivel de datos se comunica con su base de datos, su nivel de negocio se comunica con su nivel de datos y su UI se comunica con su nivel de negocio. Todas estas comunicaciones son unidireccionales (es decir, su nivel de datos no conoce el nivel comercial, etc.). Esto significa que si desea reemplazar cualquier nivel con una nueva implementación, el impacto en el resto de su programa se puede mantener al mínimo.

La implementación real que utiliza para NHibernate no es realmente relevante para el uso de MVC, excepto por el hecho de que su UI no sabrá cómo se almacenan o acceden a los datos.