Análisis comparativo de las similitudes y diferencias entre Struts Spring Hibernate y EJB3. Cuanto más detallado mejor.
1. Legalidad VS "Democracia"
Las especificaciones EJB siempre han sido formuladas por la organización internacional JCP. Una vez adoptado, se convierte en un estándar oficial y todos los fabricantes no escatimarán esfuerzos para promoverlo. Por lo tanto, para las aplicaciones empresariales, EJB es la ley y la infraestructura basada en EJB se denomina temporalmente estado de derecho. Spring proviene de la comunidad de código abierto y es un estándar de sistema popular formado gradualmente por muchos desarrolladores de software de código abierto. Su diseño se basa en IoC (Inversión de Control) y defiende el llamado principio de diseño de intrusión "cero", que temporalmente se denomina democracia.
Un servidor de aplicaciones compatible con EJB suele ser un producto grande y completo que incluye todos los aspectos necesarios para crear aplicaciones empresariales. Si requiere una expansión adicional, generalmente no es fácil. Si no está satisfecho con un servidor de aplicaciones, sólo puede reemplazar el servidor de aplicaciones completo. Afortunadamente, debido a que el mercado de servidores de aplicaciones está en auge, puede elegir entre gratuitos, de gama baja y de gama alta. Spring evolucionó a partir del contenedor IoC y proporciona un marco de aplicación empresarial perfecto al integrar continuamente AOP, MVC o /Mapping y casi todos los servicios que pueda imaginar. Para una aplicación, puedes elegir libremente la implementación de un marco técnico específico. SSH es la combinación más utilizada, pero no importa si cada arquitecto tiene la capacidad de elegir correctamente. En cualquier caso, una vez determinada la elección final al inicio del diseño, no es tan fácil cambiar. No se puede simplemente portar una aplicación basada en Spring Struts a Spring WebWork. Es aún más difícil portar fácilmente una aplicación basada en Spring Hibernate a Spring iBatis. Por lo tanto, para las aplicaciones que requieren mantenimiento y desarrollo a largo plazo, solo puede esperar que el marco que utilice pueda estar bien desarrollado y garantizar la compatibilidad futura durante la actualización. .
En definitiva, EJB es un estándar en todo el mundo, al igual que el derecho internacional. Una vez que se sigue y se usa comúnmente, puede cambiar fácilmente entre WebSphere, WebLogic e incluso JBoss, por lo que si elige EJB, obtendrá la máxima democracia en un entorno "legal" para todo el mundo. Parece ser democrático; pero una vez determinada toda la estructura, se vuelve autoritaria, igual que la democracia al estilo estadounidense. Una vez conquistada, se convierte en su dictadura. No es fácil liberarse de su control. Saboreemos los beneficios.
2. Componentes ligeros VS kernel ligero VS contenedores ligeros
Con respecto a los kernels ligeros, ya sean verdaderos o falsos, todos los servidores de aplicaciones actuales afirman utilizar tecnología de microkernels y crear varios servicios de Java EE. sobre esta base, se construye un servidor de aplicaciones perfecto; Spring en sí es un núcleo liviano basado en IoC y luego proporciona una arquitectura completa mediante la integración de servidores de terceros.
El componente EJB alguna vez se consideró un componente pesado, pero ha sido criticado. El objetivo importante de la especificación EJB3 es simplificar el desarrollo de EJB y proporcionar soluciones de componentes livianos para la gestión de contenedores.
Pero conviene recordar que los componentes ligeros no significan que el contenedor que proporciona servicios sea ligero. Ya sea EJB2 o EJB3, el servidor de aplicaciones es naturalmente un servicio pesado porque necesita gestionar el ciclo de vida y el comportamiento de los componentes y proporcionar varios servicios integrados. Al menos por ahora, los contenedores proporcionados por los servidores de aplicaciones existentes no son lo suficientemente livianos. Personalmente, me gusta JBoss 2.4. Tiene la funcionalidad que necesito y es bastante simple. Ahora la velocidad de inicio de JBoss 4 me ha hecho perder gradualmente la paciencia.
El mismo problema existe para la primavera. Un núcleo liviano no significa que todo el marco sea liviano, ni que toda la arquitectura de la aplicación basada en Spring sea liviana.
Con Spring, necesita encontrar y unir varios servicios y luego hacer que funcionen juntos de manera estable. Si la aplicación requiere más tecnología y mayor escalabilidad, continuará agregando otros servicios al servicio de la aplicación, como grupos de recursos, colas de mensajes, clústeres, etc. Si los sumamos, la solución de Spring es tan pesada como una solución de servidor de aplicaciones Java EE.
La búsqueda de la simplicidad y la ligereza es el objetivo de toda arquitectura de aplicación. Para la construcción de aplicaciones empresariales, los estándares de componentes livianos, los núcleos livianos y los contenedores livianos son los requisitos finales para construir plataformas de aplicaciones livianas. Si hay un contenedor liviano, ayudará a EJB3 a recuperar una posición favorable en las aplicaciones empresariales.
3. Manejabilidad y controlabilidad
Este problema puede no ser un problema para proyectos de entrega única, pero para productos con mayores requisitos de calidad y ciclos de vida más largos, es un factor importante en Plataforma de medición y arquitectura.
Debido a que las aplicaciones basadas en la arquitectura Spring son demasiado libres y flexibles, a medida que avanza el proyecto, se integran cada vez más marcos de terceros y es difícil garantizar si existen lagunas entre los servicios integrados y componentes, incluso conflictos graves. Entonces, es difícil controlar la calidad de todo el proyecto. Con solo mirar los archivos de configuración página tras página, sabemos que el costo de mantenimiento aumentará en el futuro. Piense en ejb-jar.xml en la era EJB2.0. Obviamente, EJB es más controlable que las aplicaciones desarrolladas por Spring porque integra todos los servicios estándar y el modelo de componente es fijo. Además, los servidores de aplicaciones suelen proporcionar una consola para ver las propiedades del tiempo de ejecución y gestionar servicios en tiempo real.
#p#
4. Comparación de funciones
4.1, contenedor IoC, función AOP
Spring es ligeramente más fuerte en IoC. se puede inyectar completamente en EJB3 y el desarrollo es mucho más sencillo. Para algunas inyecciones relativamente fijas, las anotaciones son mejores y para algunas inyecciones que pueden necesitar ser cambiadas con frecuencia, XML es más flexible que proporciona exactamente dos de esas soluciones. Si ya sufres de fobia a XML, EJB3 sin duda te ayudará a paliarla.
Al mismo tiempo, los componentes EJB3 admiten múltiples métodos de inyección, como el nombre de dependencia, la interfaz o el nombre JNDI. Además, también admite el uso de @PersistenceContext para inyectar EntityManager y @Resource para inyectar recursos del servidor, como EJBContext, TimerService, etc. Algunas anotaciones se han convertido en parte de JDK6 y es posible que JDK las admita directamente en el futuro.
Con respecto a AOP, si necesita un AOP completo e integrar AspectJ en Spring, EJB3 es naturalmente incomparable. Pero si su proyecto se basa en el principio de suficiencia, solo necesita métodos generales para interceptar AOP, y los diversos métodos de devolución de llamada proporcionados por EJB3 deberían poder cumplir con sus requisitos.
4.2. Procesamiento de transacciones
Spring también admite JTA al proporcionar TransactionTemplate e integrar procesadores de transacciones de terceros. Ambos admiten transacciones declarativas, como BMT y CMT. los órganos trasplantados no crecerán por sí solos.
4.3. Capacidades distribuidas
Las empresas que generalmente utilizan la arquitectura Java EE creen que esta es la mayor ventaja de EJB, pero la implementación no es la esperada. Por un lado, la mayoría de ellas son aplicaciones web y las capacidades distribuidas proporcionadas por la Web pueden satisfacer las necesidades del 90%. Por otro lado, básicamente todo el mundo implementa contenedores web y contenedores EJB en su conjunto, y hay muy pocas implementaciones distribuidas de componentes EJB. Por supuesto, si necesita implementar la capa web y la capa de aplicación por separado, Spring definitivamente no está dentro de su consideración.
4.4. Capacidades de agrupación en clústeres
La agrupación en clústeres también es la ventaja tradicional de EJB, pero el profesor dijo que no hay muchos lugares para aprovechar la agrupación en clústeres de EJB, porque incluso si se usa EJB. En el proyecto, generalmente no tiene estado. SessionBean reemplaza el clúster HttpSession. En este caso, no importa EJB o Spring, todos son iguales. Por supuesto, si está creando una aplicación a gran escala que tiene requisitos muy altos en cuanto a capacidades de clúster, como la agrupación en clústeres a nivel de transacción y los requisitos distribuidos, entonces probablemente no haya muchos factores que le hagan considerar la arquitectura de Web Server Spring.
4.5. Servicios de red
Los servicios web y los componentes EJB en EJB3 están muy bien integrados y son fáciles de usar. Como muestra el siguiente ejemplo, JAX-WS se convertirá gradualmente en el estándar de facto para los servicios web Java. En cuanto a Spring, se pueden implementar varios métodos de llamadas remotas basados en Http, pero las ventajas no son obvias.
@remote
@local
@ servicio web(interfaz de punto final = " jfox . prueba . EJB 3 . servicio web . calculadora ")
La clase pública CalculatorBean implementa CalculatorRemote, CalculatorLocal {
public int add(int x, int y) {
Return x y;
}
público int restar(int x, int y) {
Devolver x-y;
}
}
4.6, Marco de terceros integrado
Si necesita integrar un marco de terceros, probablemente necesite Spring. Por supuesto, la premisa es que Spring ha proporcionado una buena solución de integración, sin embargo, si usa EJB, Depende del servidor de aplicaciones específico. Se recomienda utilizarlo como biblioteca de clases o iniciarlo utilizando un detector de contexto. Sin embargo, sólo se puede integrar en función de un servidor de aplicaciones específico. En términos generales, los servidores de aplicaciones proporcionan capacidades de integración JMX.
Resumen
A lo largo de la historia de la humanidad, si el gobierno es demasiado fuerte, inevitablemente obligará al pueblo a rebelarse; si las fuerzas civiles son demasiado fuertes, la sociedad será inestable. algo que no queremos ver. Sí, ocurre lo mismo en el mundo de la tecnología. Para EJB3 y Spring, Spring tiene ahora una ventaja abrumadora. Se espera que el surgimiento del EJB3 no sólo ahorre algo de terreno perdido para el gobierno, sino que también siga generando más debates. Ya no está limitado por una sola escuela de pensamiento. Sólo en un entorno donde compiten cien escuelas de pensamiento pueden los desarrolladores y arquitectos comprender mejor la construcción de aplicaciones empresariales, por lo que la mejor manera es que EJB3 y Spring se promuevan mutuamente y se desarrollen armoniosamente.
¡Esperamos con ansias la aparición de servidores de aplicaciones EJB3 livianos que realmente se centren en las necesidades de desarrollo, inyectando nueva vitalidad al débil mercado EJB!