2009-09-17 14 views
10

Mi proyecto actual está aprovechando Spring, y nuestro arquitecto ha decidido permitir que Spring administre Servicios, Repositorios y objetos Factory, pero NO objetos de dominio. Estamos siguiendo de cerca el diseño impulsado por el dominio. El razonamiento detrás de no usar el resorte para objetos de dominio es principalmente que la primavera solo permite la inyección de la dependencia estática. Lo que quiero decir con la inyección de dependencia estática es que las dependencias se especifican dentro de la configuración xml y se "congelan".Inyección de dependencia de tiempo de ejecución con Spring

Tal vez esté mal, pero mi entendimiento actual es que aunque mi dominio solo aprovecha las interfaces para comunicarse con objetos, la configuración xml de spring me obliga a especificar una dependencia concreta. por lo tanto, todas las dependencias concretas deben resolverse en el momento del despliegue. Algunas veces, esto no es factible. La mayoría de nuestros usos se basan en la inyección de un tipo particular en función de los datos de tiempo de ejecución o un mensaje recibido de un usuario final.

La mayor parte de nuestro diseño sigue el patrón de comando. por lo tanto, cuando recibimos un comando, nos gustaría construir nuestro modelo de dominio y, en base a los datos recibidos de un comando, inyectamos un conjunto particular de tipos en nuestro objeto raíz agregado. Por lo tanto, debido a la falta de la capacidad de la primavera para construir un modelo de dominio basado en datos de tiempo de ejecución, nos vemos obligados a utilizar métodos estáticos de fábrica, constructores y patrones de Fábrica.

¿Puede alguien por favor avisar si la primavera tiene un problema con el escenario anterior?

Podría usar AOP para inyectar dependencias, pero entonces no estoy aprovechando la infraestructura de Spring.

Respuesta

2

La inyección de dependencia de Spring (y la inyección de dependencia en general) es básicamente para conectar Servicios, Repositorios y Fábricas, etc. No se supone que maneje directamente cosas que se deben hacer dinámicamente en respuesta a comandos, etc., que incluye la mayoría de las cosas con objetos de dominio. En cambio, proporciona control sobre cómo se hacen esas cosas, permitiéndole cablear los objetos que desea usar para hacerlas.

+2

Eso es vender Spring un poco corto. Es capaz de estas cosas, solo requiere un poco más de esfuerzo. – skaffman

10

Le sugiero que lea la sección en los documentos de Spring sobre Using AspectJ to dependency inject domain objects with Spring.

Es interesante que haya dicho "podría usar AOP para inyectar dependencias, pero no estoy aprovechando la infraestructura de Spring", teniendo en cuenta que AOP es una pieza central de infraestructura de Spring. Los dos van muy bien juntos.

El enlace anterior le permite tener AOP de Spring inyecciones de forma transparente en objetos de dominio que están creando sin referencia directa a la infraestructura de Spring (por ejemplo, utilizando el operador new). Es muy inteligente, pero requiere algunos retoques de carga de nivel profundo.

+0

+1. Dependiendo de la complejidad de este escenario particular, sin embargo, puede ser factible (y más fácil) usar FactoryBeans en lugar de AOP. – ChssPly76

+0

Estoy de acuerdo, normalmente no me molestaría. Sin embargo, si la aplicación es Hard-Core DDD, entonces las fábricas pueden no ser deseables. – skaffman

5

La inyección/configuración de dependencia de Spring está diseñada solo para configurar infraestructura técnica de bajo nivel, como orígenes de datos, gestión de transacciones, comunicación remota, puntos de montaje de servlets, etc.

Utilice la primavera para enrutar entre las API técnicas y sus servicios, y dentro de esos servicios simplemente escriba el código Java normal. Mantener a Spring alejado de las implementaciones de su modelo de dominio y servicio es algo bueno. Para empezar, no desea vincular la lógica de negocios de su aplicación a un marco o permitir que los problemas técnicos de bajo nivel "se filtren" en su modelo de dominio de aplicación. El código de Java es mucho más fácil de modificar en el IDE que la configuración de XML de primavera, por lo que mantener la lógica de negocio en java te permite entregar nuevas características más rápidamente y mantener la aplicación más fácilmente. Java es mucho más expresivo que el formato XML de primavera, por lo que puedes modelar conceptos de dominio más claramente si te apegas a Java simple.

+0

simplemente porque Spring PUEDE hacer muchas cosas no significa que la respuesta correcta sea hacer que su aplicación use Spring para todas esas cosas. – M1EK

+0

Si bien esto es cierto para el modelo de dominio anémico estándar, IMO está bien hacer estas cosas en un diseño impulsado por dominio (que el OP dice que está usando). –

+0

Esta respuesta aplica mucho (probablemente más) a modelos de dominio no anémicos que tienen un diseño limpio orientado a objetos e implementan la lógica de dominio como métodos en los objetos del modelo de dominio. Y los modelos de dominio anémico no son estándar. Son algo que debe * evitarse *. – Nat

Cuestiones relacionadas