¿Los aspectos sustituyen a los repositorios?

Question

Empecé a experimentar con Spring Roo recientemente. Hace un trabajo muy bueno ayudando a construir un modelo de dominio con persistencia integrada bastante rápido. Como agrega funcionalidad de persistencia en aspectos, comencé a pensar en la siguiente pregunta:

Roo agrega buscadores (carga una instancia de una clase de la base de datos que cumple criterios variables) en un aspecto a la clase/entidad real. En DDD esto es en mi humilde opinión la responsabilidad de los repositorios. Los repositorios son clases explícitas que aparecen en el diseño. Por supuesto, como aspecto, la funcionalidad del repositorio está oculta en una entidad y es prácticamente invisible.

Así que aquí está la pregunta: ¿Es un aspecto un verdadero sustituto de una clase de repositorio explícito? ¿Hay algún inconveniente en el enfoque Roo AOP?

Answer 1

Agregar buscadores a las clases de su dominio se siente más natural desde el punto de vista de un usuario, pero mezcla sus capas. Grails usa el mismo enfoque agregando el buscador estático *() save(), ... métodos.

Además de los estéticos, podría tener inconvenientes prácticos cuando no se usan en la configuración de la aplicación web: Las clases de su dominio están vinculadas a su base de datos. Si transfiere estos objetos a clientes ricos a través de RMI o HttpInvoker, el cliente no puede, y con frecuencia no puede, utilizar los métodos find * porque no hay conexión de sesión/base de datos disponible en el cliente.

Por lo general, prefiero permitir que las clases de dominio hagan referencia a las interfaces de capa de servicio para evitar un modelo de dominio anémico (http://martinfowler.com/bliki/AnemicDomainModel.html). Esto tiene su propio conjunto de inconvenientes, pero al menos proporciona un límite claro. En el cliente, la implementación concreta detrás de una interfaz de servicio puede simplemente realizar un proxy de todas las llamadas de método al servidor (o simplemente usar un proxy de sincronización con Spring Remoting o algo similar).

Para responder a su pregunta: Podría ser un sustituto, pero debe tener en cuenta las posibles consecuencias negativas que hacen que sus clases de dominio (es decir, su lógica empresarial principal) sean menos portátiles entre sistemas.

Answer 2

Esto depende de cuán complicada es la capa de persistencia de las aplicaciones y cuánto control tiene sobre ella. Si su aplicación es lo suficientemente simple como para ser implementada a través de JPA, entonces todo podría manejarse a través de aspectos de Roo. Sin embargo, si mapea tablas heredadas o necesita material avanzado de BD, entonces puede encontrarse en una situación en la que Spring-JDBC es la única salida y en estos casos un modelo de repositorio/dao puede ser útil.

Considero que es lógicamente inconsistente (y una ruptura de la responsabilidad de la capa) mezclar dos modelos de persistencia y, como la mayoría de mis aplicaciones requieren construcciones de DB tan avanzadas, me apego estrictamente a un modelo de repositorio.

Answer 3

Creo que agregar métodos de repositorio a objetos de dominio es un mal diseño. El lugar correcto sería métodos estáticos en la clase de dominio. Pero los objetos de dominio y su administración son dos cosas diferentes que deberían separarse. Preferiría objetos de dominio y repositorios.

Supongo que la motivación era lograr algo como Rails/Grails con Java.