java - ¿Diferencia entre Oracle ATG y Struts?
model-view-controller (3)
ATG es un software propietario ... y los recursos son menos ...
¿Cuál es la diferencia entre Oracle ATG y Struts?
La principal diferencia en el Reino Unido es que, como contratista de ATG, puede obtener £ 500 por día, pero como un tipo general de Struts tiene suerte de obtener £ 350.
No es que sea amargo en absoluto.
Struts es un marco para usar dentro de una aplicación web J2EE que intenta proporcionar a las aplicaciones web un enfoque basado en patrones MVC para la codificación. Incluye algunas utilidades adicionales para la validación de datos de formularios, etc. Es un proyecto de código abierto, y ha sido bastante bueno para resolver esa pieza concreta del rompecabezas de aplicaciones web, y se limita a resolver solo esa pieza en particular.
ATG (ATG Dynamo), por otro lado, es una plataforma de aplicaciones, una solución y un marco para la creación de aplicaciones web basadas en datos y contenido, principalmente para el comercio y la publicación. En el nivel de marco, es una plataforma de aplicaciones basada en Java para alojar aplicaciones basadas en web, así como componentes comerciales accesibles de RMI, con una capa ORM, un contenedor de componentes, un marco MVC y un conjunto de bibliotecas de etiquetas para JSP. El marco de componentes (The Nucleus) es un contenedor liviano para administrar el ciclo de vida y el enlace de dependencia (inyección de dependencia) de los objetos componentes Java (beans). En ese sentido, es algo similar al contenedor Spring Bean, y es el núcleo del marco ATG; todos los demás servicios y frameworks están alojados dentro de este. El marco de la capa de ORM (Repositorios) mapea objetos hacia y desde bases de datos relacionales (como era de esperar). Pero también puede manejar el mapeo con LDAP, XML y datos de sistema de archivos utilizando la misma API de acceso a datos consistente. Las etiquetas JSP para enlazar elementos de formulario en una página con valores en objetos comerciales, etc. son más elegantes y más limpias que las etiquetas de enlace de formularios en cualquier otro marco que he visto. El mecanismo de escribir sus propios equivalentes de biblioteca de etiquetas (Droplets) es mucho más consistente con la API de Servlet que las etiquetas J2EE estándar.
El marco MVC (el patrón básico de controlador de formulario) es algo similar a las clases Struts Form y Action, pero proporciona un marco mucho más básico que Struts. Fuera de la caja, y en el nivel en el que trabajan la mayoría de los desarrolladores, el modelo ATG es impulsado por la página y no controlado por el controlador. Internamente, sin duda es impulsado por el controlador con un enfoque de canalización para encadenar despachadores y controladores.
Además, el marco en el nivel básico le brinda un contenedor RMI, caché distribuido, bloqueo distribuido y singletons distribuidos, eventos distribuidos y mensajería, un programador de tareas, un motor de reglas y un mecanismo para definir flujos de trabajo de negocios con acciones y resultados personalizados, un editor gráfico para flujos de trabajo empresariales, soporte para datos versionados, soporte para roles y derechos, registro y auditoría, todos listos para usar, y todos usan API muy coherentes y consistentes
Luego, en el nivel de solución, tiene los componentes y las API para manejar perfiles de usuario, administración y personalización de identidades, creación de contenido, control de versiones y publicación, búsqueda de contenido, catálogos de productos tangibles e intangibles, búsqueda de productos y navegación guiada, fijación de precios, Cálculo de impuestos, promociones, carritos de compras, listas de regalos y listas de deseos, tipos de pago, métodos de envío, seguimiento de pedidos, gestión de relaciones con los clientes, etc.
Los puntos de extensión y los puntos de integración de ATG suelen estar muy bien diseñados y bastante bien documentados. Soportan la integración con casi cualquier persona que esté en el comercio electrónico y el espacio editorial para cosas como autoría y gestión de contenido, gestión y seguridad de identidades, catálogos de productos, búsqueda y navegación guiada, etc. Además, casi todas las áreas del marco son extensibles y plug-gable para que pueda escribir sus propios componentes para mejorarlos o reemplazarlos de la caja.
Realmente no tiene mucho sentido comparar los dos. Sin embargo, dada su pregunta, imagino que lo que realmente le interesa es la parte MVC de ATG
Para MVC, Struts le brinda más que ATG (pero luego Spring MVC le brinda incluso más que Struts). Sin embargo, tiendes a empantanarte en la mecánica del framework mucho más con Struts que con ATG.
Personalmente, creo que el modelo basado en controlador de formularios de ATG es más elegante, más limpio y más fácil de usar que la mayoría de los otros frameworks MVC web que he visto, y las API son más consistentes con las API de Servlet.
Tenga en cuenta, también, que la mayoría de los marcos ''web-MVC'' no son como MVC verdadero (es decir, el patrón utilizado para la programación de GUI en Smalltalk o incluso Java Swing, etc.). Ni Struts ni ATG proporcionan (como se diseñó) el verdadero MVC, aunque ATG realmente se acerca. Hay mucha confusión sobre la terminología.
Por ejemplo,
el modelo en MVC verdadero no es su modelo de datos ni los objetos de su modelo de dominio. Es el modelo que representa todos los datos en una vista. Si eso resulta ser un objeto de modelo de dominio, será una buena idea, pero la mayoría de las veces, encontrará que necesita un conjunto diferente de objetos de vista u objeto. Además, el modelo es responsable de mantenerse actualizado: es el modelo que interactúa con los servicios comerciales más abajo. ATG tiende a fusionar el modelo y el controlador en un componente: el manejador de formularios. Struts tiende a mantener el modelo de datos de vista distinto (el objeto de formulario), pero no fomenta su uso como modelo en el verdadero sentido de MVC: no es el objeto de formulario que interactúa con otros servicios comerciales para mantenerse actualizado.
el controlador de C en MVC no es su controlador comercial. Un controlador en MVC es un conducto entre la vista y el modelo. Reacciona a los cambios en la vista o a las acciones realizadas en la vista e instruye al modelo para que se actualice en consecuencia. En Struts, el controlador del que hablan no es un controlador MVC, en realidad es un despachador. Gran parte del código que pertenece a un controlador termina en su clase de Acción. Pero por la forma en que se diseña Struts, la clase Acción realmente pretende hacer lo que hace un Modelo.
la vista en MVC debe ser poblada por el modelo; es un mecanismo de inserción con el modelo actualizando la vista, no un mecanismo de extracción con la vista consultando el modelo. En la mayoría de los marcos web-MVC, la vista (generalmente un JSP) extrae el estado del modelo para mostrarse. Este es particularmente el caso con el enfoque basado en páginas de ATG. Si encuentra que se están obteniendo datos mientras su página se está procesando, significa que algo está mal con su diseño de MVC.
En Struts, la función del controlador MVC se extiende a través del controlador Struts y la acción, mientras que la función del modelo MVC se extiende a través del objeto Form y la acción.
En ATG, la función del Controlador MVC y el Modelo MVC está todo en el Manejador de Formularios
Una vez dicho esto, debido a la naturaleza de solicitud-respuesta de HTTP, la función de un controlador en un marco web-MVC es bastante limitada. Con las aplicaciones web, tendemos a obtener una vista completamente actualizada sobre el envío de formularios en lugar de muchos pequeños cambios (por ejemplo, cada pulsación de tecla o clic de ratón, o cada campo de entrada modificado) como lo haríamos con un marco de interfaz de usuario rico. El uso de AJAX está cambiando eso, y tenemos que pensar mucho más sobre la implementación de MVC correctamente.
Recuerde, MVC es un patrón de diseño, es decir, es un principio de tiempo de diseño que se utilizará al diseñar el aspecto de la GUI de las aplicaciones. Struts y ATG son frameworks, es decir, son clases y objetos que se extenderán, implementarán o configurarán al crear su aplicación. Un marco no puede imponer el uso de un patrón de diseño, simplemente puede alentarlo. Elegir usar un marco particular no hará que diseñe mejor su ciodo, a lo sumo puede alentar una cierta disciplina.
Si diseñas bien tu MVC, no habrá una gran diferencia si usas clases Struts o clases ATG para implementarlo. Del mismo modo, si diseñas mal tu MVC, con la esperanza de que tu elección de marco compensará tus fallas, no habrá una gran diferencia si usas Struts o ATG. Si entiende y trabaja con los principios de diseño, le resultará muy fácil cambiar entre los marcos.
El mejor código será el que se adhiere a un buen principio de diseño (por ejemplo, MVC verdadero) en abstracto, y lo implementa (lo realiza) utilizando las herramientas adecuadas disponibles en el marco elegido en la forma en que están destinadas a ser utilizadas.
Volviendo a tu pregunta;
Si está trabajando en un proyecto ATG, debe usar los marcos que proporciona ATG. Ciertamente es posible calzar a Struts en una aplicación ATG, lo he hecho hace muchos años, pero es mucho más esfuerzo de lo que vale, y está renunciando a mucho de lo que ATG ofrece de manera predeterminada en términos de gestión del ciclo de vida del objeto, enlace de datos, etc.
Si está a punto de comenzar a trabajar en un nuevo proyecto y tiene una opción de marcos para usar, personalmente recomendaría un servidor de aplicaciones de código abierto (como JBoss) y Spring Framework, que le ofrece lo mejor de lo que ofrecen ATG y Struts. Tiene un contenedor de componentes tipo Nucleus (el Contexto de la aplicación), se integra con todas las buenas soluciones ORM (como Hibernate) e incluye un marco MVC que en mi opinión ha eclipsado mucho a Struts. Además, recomendaría mirar Spring Web-flow para un diseño de flujo de GUI de mayor nivel.