Comaprison de Liferay ServiceBuilder à d'autres outils de génération de code comme AndroMDA

Question

J'ai commencé à creuser dans le framework ServiceBuilder liferay 6.x et j'ai vraiment aimé son approche de génération de code. Un simple fichier service.xml peut générer des services puissants prêts à l'emploi sans même écrire une seule ligne de code. J'ai aussi essayé AndroMDA qui peut générer des services similaires à partir du modèle UML, ce qui semble encore plus intéressant car il va lier directement mon modèle d'affaires sans avoir besoin d'apprendre une nouvelle config xml pour service.xml (en cas de liferay ServiceBuilder)

maintenant je suis en train de décider quel outil dois-je utiliser. En fonction de votre expérience avec l'un de ces outils S'il vous plaît laissez-moi savoir ce que des avantages/inconvénients de l'utilisation tout de cette bibliothèque,

Je suis intéressé de connaître ces aspects, ainsi que vos propres pensées

1. Ce qui est mieux pour garder mon développement plus productif à long terme.
2. Si j'utilise ServiceBuilder, je serai en mesure d'utiliser les services en dehors du portail env (disons exécuter le même service à partir d'un serveur d'applications non-portail)
3. Est-ce que l'approche UML est toujours bonne ou existe-t-il des inconvénients pratiques? il.

4. Connaissez-vous une autre bibliothèque de génération de code qui est mieux que ces deux pour le développement de 6.x Liferay? J'ai aussi vérifié ces SO Threads

   • Do You Use Code Generators
   • Java Code Generation

Answer 1

Il existe un fait important dont vous devez être conscient. ServiceBuilder a été utilisé pour aider à construire le portail lui-même et il est étroitement intégré dans celui-ci. Vous ne pouvez pas l'utiliser en dehors de Liferay ... Je veux dire, il pourrait probablement être pris et modifié pour un usage général, mais je doute que cela ait un sens. Plus important encore, parce que Portal et chaque plugin que vous développez ont leur propre contexte d'application Web dans un conteneur de servlet - chacun a son propre chargeur de classe. Plugins utilisent Portal classloader et services de portail, etc., etc.

Il suffit de mettre, ServiceBuilder le code généré et le contexte du printemps ne peut exister que s'il y a une webapp/ROOT/qui est le portail Liferay avec portail classloader etc.

AndroMDA est un framework MDA à usage général. Je ne le connais pas beaucoup, de sorte que je ne vais pas faire de comparaisons. La puissance de ServiceBuilder est que ce n'est pas un framework pour une utilisation générale - plus il est puissant pour le développement du plugin liferay.

Answer 2

Après quelques problèmes que je l'ai vécu avec ServiceBuilder (j'utilise Liferay 5.2.3):

1. Pas en mesure de rendre le cadre de l'utilisation ORM. Il n'y a aucun moyen de générer relations parmi les objets. Pour cette raison, je travaille effectivement juste un objet mapper.Il ne génère pas OneToMany genre de relations
2. Impossible d'utiliser l'objet de base des choses comme l'héritage orienté avec le domaine ou les services
3. Il est très difficile d'écrire des scénarios de tests unitaires
4. Je ne comprenais pas encore quel est le besoin de la structure de domaine complexe
5. je me sens le code qu'il génère peut écrire rapidement à l'aide d'un IDE

Mais certainement a ses propres avantages comme l'a dit Egar, il est spécialement conçu pour Liferay. Ainsi, il peut rapidement générer tout ce qui est nécessaire pour liferay. J'ai entendu dans les dernières versions de liferay quelques problèmes ci-dessus sont corrigés.

Dans l'ensemble, cela dépend de vos besoins. Si vous avez besoin de plus de contrôle sur votre couche ORM et que vous avez une logique métier complexe nécessitant beaucoup de tests unitaires, optez pour des services printaniers normaux qui peuvent être exposés en tant que services web ou services REST à vos portlets.

Sinon le constructeur de service est également bon pour les portlets simples. Une autre approche pourrait être d'utiliser les deux. Tous les services complexes en tant que projet distinct et simples avec le constructeur de service.