quelle est la différence entre le cadre moqui et les autres cadres

Comme cela a été souligné, il s'agit d'une question très générale. Dans l'une des réponses, il réduit la portée d'une comparaison avec Struts, donc je vais faire quelques commentaires généraux sur la façon dont Moqui est différent des autres frameworks d'application Java Enterprise (et des frameworks similaires sur d'autres langages), puis quelques points spécifiques comparant Moqui à Struts.

Certaines des lignes directrices générales de conception pour Moqui comprennent:

• Pas de mappage d'objets: Les différents outils utilisent des API dynamiques qui se comportent différemment en fonction des artefacts tels que les entités, les services et les écrans. Cela signifie qu'il n'y a pas de code redondant pour le mappage objet-relationnel, le mappage objet-service et les différents objets généralement impliqués dans la définition des interfaces utilisateur Web.
• Pas de génération de code: plutôt que d'avoir des outils de bas niveau qui nécessitent un code verbeux, puis de générer ce code basé sur une sorte d'artefact définissant des constructions de niveau supérieur, Moqui utilise simplement ces artefacts de niveau supérieur avec flexible définitions et objets/méthodes API associés pour garder la taille du code compacte et réduire la complexité du code.
• Architecture complète à 3 niveaux avec une couche logique forte en plus de l'interface utilisateur et des couches de données qui sont courantes dans la plupart des frameworks (ou piles de framework).
• Divers outils avancés basés sur les artefacts pour l'interface utilisateur, le service et les éléments de données, y compris l'autorisation consciente des artefacts (en plus des authc et authz plus génériques), les connecteurs d'intégration d'entreprise, les moteurs de règles et de flux de travail (en utilisant Drools / jBPM), recherche basée sur ElasticSearch avec des données relationnelles combinées dans des documents et alimentées aux index via la configuration uniquement, et bien plus encore.
• La configuration est dans les fichiers et non dans la base de données comme c'est le cas pour les frameworks de nombreux systèmes ERP. Cela rend plus flexible, plus facile d'étendre les fonctionnalités (via des macros supplémentaires pour interpréter les éléments XML) et de permettre des points d'injection de modèle et de code n'importe où dans les artefacts (et sans générer puis la modification de code).

Sur la page référencée dans la réponse de Thrash Bean, il y a une section comparant Moqui à Apache OFBiz, qui est le projet d'où proviennent de nombreux concepts de Moqui. Je suis l'auteur du cadre Moqui, et a commencé le projet OFBiz en 2001 et a conduit une grande partie de la conception du cadre OFBiz.

Http://www.moqui.org/framework/index.html

Comparer Moqui à quelque chose comme Struts entraîne des différences plus significatives, bien qu'elles soient SI différent que la liste n'est pas si longue car elle doit rester à un niveau élevé pour comparer des concepts similaires dans les deux outils.

Tout d'abord, Apache Struts est un framework d'interface utilisateur Web pour coordonner les requêtes Web, le traitement des entrées et les liens vers d'autres outils pour les réponses HTML et autres (JSON, etc.). Ce n'est qu'une petite partie de la fonctionnalité globale que Moqui offre, car l'intention de Moqui est d'inclure tout ce qui est couramment nécessaire dans les applications d'automatisation d'entreprise (c'est-à-dire ERP, CRM, commerce électronique, etc).

Struts est couramment utilisé avec Hibernate ou une sorte d'implémentation JPA pour persistant, et Moqui utilise une approche très différente sans mappage objet-relationnel pour la persistance (la façade d'entité).

La partie de Moqui qui correspond à Struts est les écrans XML et les "transitions" dans ces écrans qui traitent l'entrée des demandes et redirigent le navigateur vers l'écran configuré pour répondre.

Pour des exemples d'écrans et de transitions voir le tutoriel sur le moqui.org site:

Http://www.moqui.org/framework/docs/Tutorial.html

Les différents concepts liés aux définitions d'écran et de transition commencent dans la section "Ajouter un écran" et sont développés dans les sections "Formulaire de recherche automatique", "Ajouter un formulaire de création" et "Service de création personnalisé".

Toutes mes excuses pour la longue réponse... il aurait peut-être été préférable de fermer cette question et de demander des questions plus spécifiques. De toute façon, n'hésitez pas à demander de plus questions spécifiques...