Différence entre Oracle ATG et Struts? [fermé]


Fermé. Cette question doit être plus concentré. Il n'accepte pas actuellement de réponses.

Vous voulez améliorer cette question? Mettez à jour la question pour qu'elle se concentre sur un seul problème en modifiant ce post.

Fermé il y a 7 ans.

Améliorer cette question

Quelle est la différence entre Oracle ATG et Struts?

Author: Roman C, 2008-12-26

3 answers

Struts est un framework à utiliser dans une application Web J2EE qui essaie de fournir aux applications Web une approche de codage basée sur un modèle MVC. Il comprend des utilitaires supplémentaires pour la validation des données de formulaire,etc. C'est un projet open source, et a été très bon pour résoudre cette pièce particulière du puzzle de l'application Web, et se limite à résoudre cette pièce particulière.

ATG (ATG Dynamo), d'autre part, est une plate-forme d'application - une solution et un framework - pour créer des applications Web axées sur les données et le contenu, principalement pour le commerce et la publication. Au niveau du framework, il s'agit d'une plate-forme d'application basée sur Java pour héberger des applications Web, ainsi que des composants métier accessibles RMI, avec une couche ORM, un conteneur de composants, un framework MVC et un ensemble de bibliothèques de balises pour JSP. Le component framework (Le Nucleus) est un conteneur léger pour gérer le cycle de vie et la liaison de dépendance (injection de dépendance) du composant Java des objets (des haricots). En ce sens, il est quelque peu similaire au conteneur Spring bean et constitue le cœur du framework ATG - tous les autres services et frameworks y sont hébergés. Le cadre de couche ORM (référentiels) mappe les objets vers et depuis les bases de données relationnelles (comme vous vous y attendez). Mais il peut également gérer le mappage avec des ources de données LDAP, XML et système de fichiers en utilisant la même API d'accès aux données cohérente. Les balises JSP pour lier des éléments de formulaire sur une page à des valeurs sur des objets métier,etc. sont plus élégant et plus propre que les balises de liaison de formulaire dans tout autre cadre que j'ai vu. Le mécanisme d'écriture de vos propres équivalents de bibliothèque de balises (Gouttelettes) est beaucoup plus cohérent avec l'API Servlet que les balises J2EE standard.

Le framework MVC (le modèle de gestionnaire de formulaire de base) est quelque peu similaire aux classes de forme et d'action Struts - mais fournit un framework beaucoup plus basique que Struts. Prêt à l'emploi, et au niveau auquel la plupart des développeurs travaillent, le modèle ATG n'est pas piloté par la page piloté par le contrôleur. En interne, il est certainement piloté par le contrôleur avec une approche de pipeline pour chaîner les répartiteurs et les contrôleurs.

En outre, le framework au niveau de base vous donne un conteneur RMI, une mise en cache distribuée, un verrouillage distribué et des singletons distribués, des événements et des messages distribués, un planificateur de tâches, un moteur de règles et un mécanisme pour définir des workflows métier avec des actions et des résultats personnalisés, un éditeur graphique pour les workflows métier, données versionnées, prise en charge des rôles et des droits, journalisation et audit - le tout prêt à l'emploi, et le tout en utilisant des API très cohérentes et cohérentes

Ensuite, au niveau de la solution, vous avez les composants et les API pour traiter le profilage des utilisateurs, la gestion et la personnalisation des identités, la création de contenu, le versioning et la publication, la recherche de contenu, les catalogues de produits pour les biens corporels et incorporels, la recherche de produits et la navigation guidée, les prix, le calcul listes et listes de souhaits, types de paiement, méthodes d'expédition, suivi des commandes, gestion de la relation client, etc.

Les points d'extension et les points d'intégration à ATG sont généralement très bien conçus et assez bien documentés. Ils prennent en charge l'intégration avec à peu près n'importe qui qui est n'importe qui dans le commerce électronique et l'espace de publication pour des choses comme la création et la gestion de contenu, la gestion et la sécurité des identités, les catalogues de produits, la recherche et la navigation guidée, etc. Aussi, presque tous les domaines de la framework sont extensibles et plug-gable afin que vous puissiez écrire vos propres composants pour améliorer ou remplacer ceux prêts à l'emploi.

Cela n'a pas vraiment de sens de comparer les deux. Cependant, compte tenu de votre question, j'imagine que ce qui vous intéresse vraiment est la partie MVC d'ATG

Pour MVC, Struts vous donne plus que ATG (mais Spring MVC vous donne encore plus que Struts). Cependant, vous avez tendance à vous enliser dans la mécanique du cadre beaucoup plus avec des entretoises qu'avec de l'ATG.

Personnellement, je pense que le modèle basé sur le gestionnaire de formulaires d'ATG est plus élégant, plus propre et plus facile à utiliser que la plupart des autres frameworks web MVC que j'ai vus, et les API sont plus cohérentes avec les API de Servlet.

Gardez également à l'esprit que la plupart des frameworks "web-MVC" ne sont pas comme true MVC (c'est-à-dire le modèle utilisé pour la programmation GUI dans Smalltalk ou même Java Swing, etc.). Ni les entretoises ni ATG ne fournissent (tel que conçu) un véritable MVC - bien qu'ATG se rapproche réellement. Y est beaucoup de confusion sur la terminologie.

Par exemple

  1. Le M odel dans true MVC n'est pas votre modèle de données ni vos objets de modèle de domaine. C'est le modèle qui représente toutes les données dans une vue. Si cela se trouve être un objet de modèle de domaine, alors bien et bien - mais le plus souvent, vous constaterez que vous avez besoin d'un ensemble différent d'objets de vue ou de formulaire. En outre, le modèle est responsable de se tenir à jour - c'est le modèle qui interagit avec les entreprises services plus bas. ATG a tendance à fusionner le modèle et le contrôleur en un seul composant - le gestionnaire de formulaire. Struts a tendance à garder le modèle de données view distinct (l'objet form), mais n'encourage pas son utilisation en tant que modèle dans le vrai sens MVC - ce n'est pas l'objet form qui interagit avec d'autres services métier pour se tenir à jour.

  2. Le C ontroller dans MVC n'est pas votre contrôleur de gestion. Un contrôleur dans MVC est un conduit entre la vue et le modèle. Il réagit aux modifications de la vue ou aux actions effectuées sur la vue et demande au modèle de se mettre à jour en conséquence. Dans Struts, le contrôleur dont ils parlent n'est pas du tout un contrôleur MVC - c'est vraiment un répartiteur. Une grande partie du code qui appartient à un contrôleur se retrouve dans votre classe d'Action. Mais de la façon dont Struts est conçu, la classe Action est vraiment destinée à faire ce qu'un modèle fait.

  3. Le View MVC doit être rempli par le modèle - c'est une poussée mécanisme avec le modèle mettant à jour la vue, pas un mécanisme d'extraction avec la vue interrogeant le modèle. Dans la plupart des frameworks web-MVC, la vue (généralement un JSP) extrait l'état du modèle afin de s'afficher. C'est particulièrement le cas de l'approche axée sur les pages d'ATG. Si vous constatez que des données sont récupérées pendant le rendu de votre page, cela signifie que quelque chose ne va pas avec votre conception MVC.

Dans Struts, la fonction du contrôleur MVC est répartie sur le contrôleur Struts et l'Action, tandis que la fonction du modèle MVC est répartie sur l'objet de formulaire et l'Action.

Dans ATG, la fonction du contrôleur MVC et du modèle MVC est dans le gestionnaire de formulaire

Cela dit, en raison de la nature requête-réponse de HTTP, la fonction d'un contrôleur dans un framework web-MVC est assez limitée. Avec les applications Web, nous avons tendance à obtenir une vue complètement mise à jour sur la soumission de formulaire plutôt que de nombreux petits changements (par exemple, chaque pression sur une touche ou un clic de souris, ou chaque champ de saisie modifié) comme nous le ferions avec un cadre d'interface utilisateur riche. L'utilisation d'AJAX change cela - et nous devons réfléchir beaucoup plus à l'implémentation correcte de MVC.

Rappelez - vous, MVC est un modèle de conception-c'est-à-dire qu'il s'agit d'un principe de temps de conception à utiliser lors de la conception de l'aspect GUI des applications. Struts et ATG sont des frameworks, c'est-à-dire des classes et des objets à étendre, implémenter ou configurer lors de la création de votre application. Un cadre ne peut pas imposer l'utilisation d'une conception modèle - il peut simplement l'encourager. Choisir d'utiliser un cadre particulier ne vous fera pas mieux concevoir votre ciode - tout au plus cela peut encourager une certaine discipline.

Si vous concevez bien votre MVC, cela ne fera pas une énorme différence si vous utilisez des classes Struts ou des classes ATG pour l'implémenter. De même, si vous concevez mal votre MVC, en espérant que votre choix de framework compensera vos lacunes, cela ne fera pas une énorme différence que vous utilisiez Struts ou ATG. Si vous comprendre et travailler avec les principes de conception, vous trouverez qu'il est très facile de basculer entre les cadres.

Le meilleur code sera celui qui adhère à un bon principe de conception (disons, true MVC) dans l'abstrait, et l'implémente (le réalise) en utilisant les bons outils disponibles dans le cadre choisi de la manière dont ils sont destinés à être utilisés.

Revenir à votre question;

Si vous travaillez sur un projet ATG, vous devez utiliser les frameworks que ATG fournit. Il est certainement possible de se pavaner dans une application ATG - je l'ai fait moi - même il y a de nombreuses années - mais c'est beaucoup plus d'efforts que cela en vaut la peine-et vous abandonnez beaucoup de ce que ATG fournit hors de la boîte en termes de gestion du cycle de vie des objets, de liaison de données.

Si vous êtes sur le point de commencer à travailler sur un nouveau projet et que vous avez un choix de frameworks à utiliser - je recommanderais personnellement un serveur d'applications open source (comme JBoss) et le framework Spring - il vous donne le meilleur de ce que ATG et Struts fournissent. Il a un conteneur de composants de type noyau (le contexte de l'application), il s'intègre à toutes les bonnes solutions ORM (telles que Hibernate) et inclut un framework MVC qui, à mon avis, a largement éclipsé Struts. En outre, je recommanderais de regarder Spring Web-flow pour une conception de flux GUI de niveau supérieur.

 59
Author: Vihung, 2013-12-21 08:48:42

La principale différence au Royaume-Uni est qu'en tant qu'entrepreneur ATG, vous pouvez obtenir £500 par jour, mais en tant que general Struts guy, vous avez de la chance d'obtenir £350.

Pas que je sois amer du tout.

 9
Author: Gareth Davis, 2013-05-15 21:08:43

ATG est un logiciel propriétaire... et les ressources sont moindres ...

 -1
Author: Sameer, 2010-04-05 10:03:13