Lorsque vous lisez les exigences de la prochaine application Web d'entreprise à usage interne, alors généralement (à en juger par mon expérience), il s'agit d'un seul et même ensemble: une base de données relationnelle pour stocker des données, souvent héritée de la version précédente de l'application, un grand nombre de formes de différents niveaux de difficulté (mais en même temps typique) pour la saisie de données, une variété de formulaires de rapport, une logique métier complexe, l'intégration avec d'autres applications - de la comptabilité à la gestion des approvisionnements, plusieurs milliers d'utilisateurs travaillant simultanément. Qu'est-ce qui vous vient généralement à l'esprit?

"Je vais donc prendre le SGBD que je connais et qui correspond à leurs volumes de données, fixer Hibernate / JPA, écrire l'application sur Spring Boot, exposer l'API REST et écrire le client sur le framework JS, très probablement Angular / React."

«Oui, nous devons encore visser Spring Security. Et rédigez une restriction sur l'accès aux données pour différents services et rôles - au niveau des lignes de base de données ou des objets de données. Comment faire Soumission ou VPD, vous devrez regarder. "

"Ugh, je dois écrire un tas de DAO - ils sont faits rapidement, mais ils sont nombreux."

"Et la conversion d'Entity en DTO - j'utilise ModelMapper ."

"L'essentiel est de ne pas oublier de rappeler au stagiaire les attributs paresseux et les jointures pour qu'il n'y en ait pas, comme la dernière fois."

"Sapins, pendant que vous démarrez la logique métier, vous devez écrire tellement de code de service ..."

Cet article s'adresse à ceux qui ont écrit au moins quelques applications d'entreprise à partir de zéro sur Spring / Spring Boot et pensent maintenant qu'il serait bien d'accélérer le développement d'applications aussi différentes, mais en même temps, similaires. Ensuite, nous verrons comment se débarrasser des tâches «typiques» en utilisant la plateforme CUBA .

Un autre cadre?

Pensée numéro un, lorsque le développeur se voit proposer un nouveau framework (et, en particulier, CUBA), c'est: «Pourquoi devrais-je m'embêter avec ça? Je vais prendre le Spring Boot familier et familier et je vais tout faire. " Et c'est raisonnable. Le nouveau cadre est l'étude de nouvelles approches de développement, de nouveaux pièges et limites que vous avez appris à éviter intelligemment lors du développement dans un cadre familier.

Mais, quand j'ai commencé à développer sur CUBA, je n'ai pas eu beaucoup à changer mes compétences avec Spring. Naturellement, j'ai dû passer un peu de temps à comprendre la plate-forme, mais ce n'était pas une rupture radicale de toutes les habitudes, mais plutôt un petit changement dans les compétences de développement.
En conséquence, le code DTO, la sortie des données page par page, le filtrage des données (analyse des paramètres transférés dans le formulaire et compilation des requêtes) ont disparu. Dans le même temps, je n'ai presque pas eu à bricoler les paramètres de Spring Security et à écrire du code administrateur, des formulaires de connexion et une logique de commutation de langue d'interface utilisateur.

Commençons par le tout début et voyons comment le développement de CUBA se compare à la façon habituelle de développer sur Spring et comment, en utilisant votre expérience et en apprenant quelques nouvelles choses, vous pouvez finalement créer des applications plus rapidement.

L'objectif principal de l'article est le développement du côté serveur afin de ne pas perdre le focus et de maintenir la quantité de texte à un niveau acceptable.

Architecture d'application Spring

Dans 90% des cas, en tapant Google "Spring Application Architecture" ou "Spring application architecture", vous verrez une image similaire. Une application classique à trois couches avec des modules communs à certaines couches.



Modèle de domaine (modèle de domaine) - classes d'entités du domaine (entités), généralement stockées dans la base de données. Les classes sont généralement créées manuellement, mais vous pouvez créer la structure automatiquement, en fonction du schéma de la base de données.

Couche de référentiel (couche de référentiel) - un ensemble de classes qui permettent de travailler avec l'entrepôt de données. En règle générale, cette couche utilise divers cadres ORM et contient une logique pour effectuer des opérations CRUD. Si nous parlons de Spring, les référentiels sont assez compacts, principalement en raison des méthodes de requête JPA, mais souvent vous devez écrire la logique de sélection à partir de la base de données et la mapper manuellement au modèle de domaine.

Couche de service - une couche d'application qui contient l'implémentation de la logique métier, des algorithmes de traitement de l'information spécifiques au domaine. Cela est utile dans le cas d'algorithmes de traitement complexes, ainsi que pour travailler avec des données provenant de diverses sources (bases de données, applications externes, services Internet, etc.).

Couche Web / Contrôleurs - classes responsables de l'API REST. Il peut également y avoir des fichiers de modèle de page sur cette couche si nous utilisons un cadre comme Thymeleaf, Velocity, ainsi que des classes responsables du rendu et de la gestion des événements de l'interface utilisateur si quelque chose comme GWT, Vaadin, Wicket, etc. est utilisé. En règle générale, les contrôleurs fonctionnent avec DTO, et non avec les classes de la couche domaine, de sorte que la fonctionnalité de conversion de DTO en entité et vice versa est ajoutée à l'application.
Si tout ce qui précède est évident pour vous, ou même «capitaine ordinaire» est excellent. Vous pouvez donc commencer à travailler avec CUBA sans aucun problème.

Application de référence - Pet Clinic

Regardons un exemple spécifique et écrivons du code. Pour le printemps, il existe une application «référence» - Pet Clinic sur GitHub . Cette application a été créée dans différentes versions en utilisant différents outils - du classique Spring à Kotlin et Angular. Ensuite, nous verrons comment faire cette application sur CUBA. Pour ceux qui ne connaissent pas la version Spring, il y a du bon texte ici ; des extraits de celui-ci seront utilisés dans cet article.

Modèle de données

Le diagramme ER est illustré dans la figure ci-dessus. Le modèle de domaine répète cette structure, plusieurs classes avec des champs communs y sont ajoutées et les classes d'entités en sont déjà héritées. UML se trouve dans la présentation que j'ai mentionnée plus tôt.

Couche de référentiel

Il existe quatre référentiels dans l'application qui sont chargés de travailler avec les entités Propriétaire (Propriétaire), Pet (Pet), Visit (Visit) et Vet (Veterinarian). Les référentiels sont écrits à l'aide de Spring JPA et ne contiennent pratiquement aucun code, uniquement des déclarations de méthode. Cependant, une requête a été ajoutée au référentiel qui fonctionne avec l'entité Propriétaire, ce qui permet d'extraire les propriétaires et leurs animaux de compagnie de la base de données dans un échantillon.

Interface utilisateur

Pet Clinic a neuf pages qui vous permettent de voir une liste des propriétaires, leurs animaux de compagnie et une liste de vétérinaires. L'application fournit une fonctionnalité CRUD simple: il est possible de modifier certaines données - propriétaires, animaux de compagnie et vous pouvez également ajouter des visites à la clinique. Mais, comme déjà mentionné, nous ne discuterons pas en profondeur de l'interface utilisateur dans cet article.

En option

En plus du code pour des manipulations simples avec des entités, l'application possède des fonctionnalités intéressantes conçues pour montrer les capacités de Spring:

• Mise en cache - la liste des vétérinaires n'est sélectionnée dans la base de données qu'une seule fois, puis elle est stockée dans le cache jusqu'au redémarrage du serveur d'applications.
• Vérifier l'achèvement des champs obligatoires lors de la saisie d'informations sur un nouvel animal.
• Formatage du type d'animal avant de l'afficher.
• i18n - l'application prend en charge l'anglais et l'allemand.
• Gestion des transactions - Certaines transactions sont marquées en lecture seule.

Notes marginales

J'aime beaucoup cette photo. Cela reflète à 100% mes sentiments lorsque je travaille avec des frameworks. Pour utiliser le framework efficacement, vous devez comprendre comment il est construit à l'intérieur (quoi qu'il arrive). Par exemple, combien d'entre vous se sont demandés combien de classes étaient nécessaires pour faire fonctionner l'interface JPA?
Même dans une petite application comme Pet Clinic, il y a un peu de magie Spring Boot:

• Il n'y a pas de configuration pour le cache (à l'exception de l'annotation @Caheable ), cependant, Spring Boot "sait" comment démarrer le cache souhaité (EhCache dans ce cas).
• Les référentiels CRUD ne sont pas marqués avec @Transactional annotation @Transactional (et leur classe parente est org.springframework.data.repository.Repository également), mais toutes les méthodes save() fonctionnent comme prévu.

Mais, malgré tous les "implicites", Spring Boot est très populaire. Pourquoi? Il est transparent et prévisible. Une bonne documentation et un code open source permettent de comprendre les principes et, si nécessaire, de se plonger dans les détails d'implémentation. Il me semble que tout le monde aime ces cadres, la transparence et la prévisibilité - la clé de la stabilité et de la maintenabilité de l'application.

Pet Clinic sur la plateforme CUBA

Eh bien, regardons la Pet Clinic, qui a été créée en utilisant CUBA, du point de vue du développeur Spring et essayons de comprendre où vous pouvez économiser.

Le code source de l'application se trouve sur GitHub . De plus, la plate-forme CUBA dispose d'une documentation très correcte en russe et en anglais, qui explique en détail comment se développer correctement sur cette plate-forme. De nombreux exemples sur GitHub , dont plusieurs tutoriels. Dans l'article, je ferai souvent référence à la documentation, afin de ne pas écrire deux fois la même chose.

Architecture d'application CUBA

L'application CUBA se compose des modules illustrés dans le diagramme.



Global (module global) - contient des classes d'entités, des représentations CUBA et des interfaces de service utilisées dans différents modules.

Core (module de service) - c'est là que le code des services qui implémentent la logique métier, ainsi que le code pour travailler avec l'entrepôt de données, sont placés. Il convient de noter que ces classes ne sont pas disponibles à partir d'autres modules d'application, ceci est effectué afin de fournir un déploiement séparé pour une meilleure évolutivité. Pour utiliser les services dans d'autres modules d'application, vous devez utiliser les interfaces déclarées dans le module global.

GUI, Web, Desktop, Portal - ces modules contiennent du code pour les classes liées au traitement des événements de l'interface utilisateur, ainsi que des contrôleurs REST supplémentaires si l' API REST CUBA intégrée n'est pas suffisante.

Pour gagner du temps aux développeurs, CUBA dispose d'un studio - un petit environnement de développement graphique qui aide à effectuer des tâches de routine, telles que la génération d'entités, l'enregistrement de services dans des fichiers de configuration, etc. en utilisant l'interface graphique. Pour générer l'interface de l'application développée, il existe un (presque) éditeur WYSIWYG.

Ainsi, l'application basée sur la plate-forme CUBA se compose de deux modules principaux - Core et GUI, qui peuvent être déployés séparément, ainsi que d'un module commun - Global. Examinons de plus près la conception de ces modules.

Module global

Modèle d'entité

La modélisation d'entités dans une application CUBA n'est pas différente de ce à quoi les développeurs Spring sont habitués. Les classes de domaine sont créées et des annotations @Table , @Entity , etc. sont placées dessus. Ces classes sont ensuite enregistrées dans le fichier persistence.xml .

Lors de l'écriture de Pet Clinic, je viens de copier les cours de l'application Spring originale et de les changer un peu. Voici quelques petits ajouts que vous devez savoir si vous écrivez sur la plateforme CUBA:

1. CUBA introduit le concept d '« espace de noms » pour chaque composant de l' application afin d'éviter la duplication des noms de table dans la base de données. C'est pourquoi le préfixe «petclinic $» a été ajouté à chaque entité.
2. Il est recommandé d'utiliser l'annotation @NamePattern - un analogue de la toString() pour un affichage lisible des entités dans l'interface utilisateur.

Question naturelle: "Qu'est-ce que CUBA ajoute d'autre que les préfixes et le déclaratif toString() ?" Voici une liste partielle des fonctionnalités supplémentaires:

1. Classes de base avec des ID générés automatiquement de Integer à UUID.
2. Interfaces de marqueur utiles qui offrent des fonctionnalités supplémentaires:
   
   • Versioned - pour prendre en charge la version des instances d'entité.
   • SoftDelete - pour prendre en charge la suppression «logique» des enregistrements dans la base de données.
   • Updatable - des champs sont ajoutés pour enregistrer le fait de mettre à jour l'enregistrement, le nom d'utilisateur et l'heure.
   • Creatable - des champs sont ajoutés pour enregistrer la création d'un enregistrement.
   
   Vous pouvez en savoir plus sur la modélisation d'entités dans la documentation .
3. Les scripts de création et de mise à jour de la base de données sont générés automatiquement à l'aide de CUBA Studio.

Ainsi, la création d'un modèle de données pour Pet Clinic s'est résumée à la copie de classes d'entités et à l'ajout de choses spécifiques à CUBA, que j'ai mentionnées ci-dessus.

Vues

Le concept de «représentations» dans CUBA peut sembler quelque peu inhabituel, mais il est assez facile à expliquer. Une vue est un moyen déclaratif de déclarer des attributs dont les valeurs doivent être extraites de l'entrepôt de données.

Par exemple, vous devez extraire les propriétaires et leurs animaux de compagnie de la base de données (ou les vétérinaires et leur profession) - une tâche très courante lors de la création d'une interface consiste à afficher les données dépendantes sous la même forme que la principale. Au printemps, cela peut se faire via une jointure JPA ...

 @Query("SELECT owner FROM Owner owner left join fetch owner.pets WHERE owner.id =:id") public Owner findById(@Param("id") int id); 

... ou définissez les attributs EAGER / LAZY pour récupérer la collection de l'entité principale dans le contexte d'une seule transaction.

 @ManyToMany(fetch = FetchType.EAGER) @JoinTable(name = "vet_specialties", joinColumns = @JoinColumn(name = "vet_id"), inverseJoinColumns = @JoinColumn(name = "specialty_id")) private Set<Specialty> specialties; 

Dans CUBA, vous pouvez le faire via EntityManager et JPQL (tout le monde sait comment) ou via la vue et DataManager:

1. Former une présentation (peut être fait dans CUBA Studio ou manuellement dans la configuration)
   
   

    <view class="com.haulmont.petclinic.entity.Vet" extends="_minimal" name="vet-specialities-view"> <property name="specialities" view="_minimal"> </property> </view> 

2. Et utilisez le DataManager pour récupérer:

    public Collection<Vet> findAll() { return dataManager.load(Vet.class) .query("select v from cubapetclinic$Vet v") .view("vet-specialities-view") .list(); } 

Vous pouvez créer différentes vues pour différentes tâches avec l'ensemble d'attributs et les niveaux d'imbrication d'entités souhaités. Il y a un excellent article sur les articles du blog de Mario David.

Six soumissions différentes ont été faites pour l'application Pet Clinic. La plupart d'entre eux ont été générés «semi-automatiquement» lors de la création de l'interface utilisateur, et la vue décrite ci-dessus a été implémentée pour le service d'exportation de données.

Interfaces de service

Étant donné que le module global est utilisé par tous les autres modules d'application, les interfaces de service y sont déclarées, afin qu'elles puissent être utilisées ultérieurement dans d'autres modules via le mécanisme d'injection de dépendance (DI).

De plus, vous devez enregistrer les services dans le web-spring.xml du module Web. Lors de l'initialisation du contexte, CUBA créera des classes proxy pour la sérialisation et la désérialisation des classes lors de l'interaction avec les services du module Core. Cela fournit simplement un déploiement séparé des modules Core et Web, tandis que le développeur n'a pas besoin de faire des efforts supplémentaires, tout est fait de manière transparente.

Donc: lors de la création de classes d'entités dans CUBA, le même temps est passé que dans Spring pur (si vous n'utilisez pas CUBA Studio), mais vous n'avez pas besoin de créer des classes de base pour générer des clés primaires. De plus, vous n'avez pas besoin d'écrire du code pour prendre en charge le champ de version d'entité, la suppression logique et l'audit. De plus, à mon avis, les vues peuvent gagner un peu de temps sur le débogage de la jointure JPA et la manipulation des échantillons EAGER / LAZY.

Module de base

Ce module contient les implémentations des interfaces déclarées dans le module global. Chaque service d'une application CUBA est annoté par @Service , vous pouvez utiliser d'autres annotations Spring, mais vous devez tenir compte des éléments suivants:

• Si vous souhaitez que le service soit disponible dans d'autres modules, vous devez définir l'annotation @Service .
• Il est recommandé de nommer le service afin d'éviter la duplication si un composant apparaît dans l'application qui implémente la même interface.
• L'échantillonnage des données se fait un peu différemment qu'au printemps, plus à ce sujet dans la section suivante.

Sinon, le module Core est du code Spring normal. Vous pouvez sélectionner des données dans la base de données, vous pouvez appeler des services Web externes, en général, écrire du code comme vous en avez l'habitude.

Entity Manager et DataManager

La plateforme CUBA utilise son propre EntityManager , qui délègue une partie des appels au familier javax.persistence.EntityManager , mais javax.persistence.EntityManager pas cette interface. EntityManager fournit principalement des opérations de bas niveau et ne prend pas entièrement en charge le modèle de sécurité CUBA. La classe principale pour travailler avec des données est le DataManager, qui fournit les fonctionnalités suivantes:

• Contrôle d'accès au niveau des lignes et des attributs.
• Utilisation de vues lors de la récupération des données.
• Attributs dynamiques.

Plus d'informations sur DataManager et EntityManager sont écrites dans la documentation . Il n'est pas nécessaire de travailler explicitement avec ces classes pour sélectionner des données dans des composants d'interface utilisateur (tables, etc.), les sources de données (Datasources) sont utilisées dans l'interface graphique.

Si nous parlons de PetClinic - il n'y a presque pas de code dans le module Core, il n'y a pas de logique métier complexe dans cette application.

Fonctionnalités supplémentaires de Pet Clinic à CUBA

Dans la section précédente, des fonctionnalités supplémentaires ont été prises en compte dans l'application de référence. Étant donné que CUBA utilise Spring, la même fonctionnalité est également disponible lors du développement sur la base de cette plate-forme, mais vous devrez vous passer de la magie de Spring Boot. En plus de cela, CUBA offre des fonctionnalités prêtes à l'emploi similaires.

Mise en cache

La plateforme CUBA dispose d'un cache de requêtes et d'un cache d'entités. Elles sont décrites en détail dans la documentation et peuvent être considérées comme des solutions prioritaires si vous souhaitez utiliser la mise en cache dans l'application. Les solutions intégrées prennent en charge le déploiement et le clustering d'applications distribuées. Eh bien, bien sûr, vous pouvez utiliser l'annotation @Cacheable , comme décrit dans la documentation Spring , si la mise en cache intégrée ne fonctionne pas pour quelque chose.

Vérification d'entrée

CUBA utilise BeanValidation pour valider les données saisies. Si les classes intégrées ne fournissent pas les fonctionnalités nécessaires, vous pouvez écrire votre propre logique de vérifications . Et, en plus de cela, CUBA fournit des classes Validator , qui sont décrites ici .

Formatage de sortie

La plate-forme CUBA fournit plusieurs formateurs pour les composants de l'interface utilisateur, vous pouvez également créer les vôtres en plus de la norme. Vous pouvez utiliser l'annotation @NamePattern pour représenter les instances d'entité sous forme de chaîne

i18n

CUBA prend en charge la sortie multilingue à l' aide de fichiers message.properties , rien de nouveau ici. CUBA Studio permet de créer et de modifier de tels fichiers rapidement et facilement.

Gestion des transactions

Les types de gestion des transactions suivants sont pris en charge:

• Familier de l'annotation Spring @Transactional ,
• Interface de Persistence (et classe) si vous avez besoin d'une gestion des transactions de bas niveau.

Lorsque j'ai écrit Pet Clinic, je n'avais besoin de la gestion des transactions qu'en un seul endroit: lorsque j'ai développé un formulaire de saisie qui m'a permis de modifier plusieurs entités liées sur un seul écran. Il était nécessaire de modifier les propriétaires et leurs animaux de compagnie, ainsi que d'ajouter des visites à la clinique. Il était nécessaire de stocker soigneusement les données et de les mettre à jour sur d'autres écrans.

Clinique pour animaux de compagnie en quelques heures. Vraiment

J'ai fait une copie de Pet Clinic avec l'interface CUBA standard en six heures. Cela ne veut pas dire que je suis un expert en CUBA (quelques semaines se sont écoulées depuis que j'ai commencé à travailler chez Haulmont), mais j'ai de l'expérience avec Spring et cela m'a beaucoup aidé.

Jetons un coup d'œil à l'application CUBA en termes d'architecture classique:

Modèle de données - classes d'entités dans le module Global. La création d'un modèle est une procédure bien connue et familière. Merci à la classe BaseIntegerIdEntity pour avoir économisé le temps qu'il faut habituellement pour jouer avec la génération d'ID.

La couche de référentiel n'est pas nécessaire. J'ai créé plusieurs vues, et c'est tout. Bien sûr, CUBA Studio m'a fait gagner un peu de temps, je n'ai pas eu à écrire manuellement des fichiers XML.

Couche de service - l'application ne dispose que de deux services pour exporter des données vers JSON et XML. Dans la version actuelle de l'application Spring Boot, cette fonctionnalité a été supprimée, soit dit en passant. Bien que cela n'ait pas fonctionné pour JSON. Dans la version CUBA, j'ai déclaré des interfaces dans le module global et mis l'implémentation dans Core. Rien de nouveau, sauf le DataManager, mais il a fallu très peu de temps pour le maîtriser.

Couche de contrôleur - CUBA Pet Clinic ne dispose que d'un seul contrôleur REST pour l'exportation vers JSON et XML. J'ai placé ce contrôleur dans le module Web. Encore une fois, rien de spécial, les annotations sont les mêmes, un contrôleur Spring régulier.

L'interface utilisateur - créer des formulaires CRUD standard, et même avec CUBA Studio, n'a pas posé de problème. Pas besoin d'écrire du code pour transférer des données vers des composants, pas d'analyse de données à partir du formulaire de filtrage des données, pas de problème avec la pagination. Il y a des composants pour tout cela. Il a fallu du temps pour que l'interface ressemble à celle de la version Spring Boot. Vaadin n'est toujours pas du HTML pur, et c'était plus difficile à styliser.

L'expérience personnelle a tabulé:

	Facile à comprendre, facile à faire	J'ai besoin de lire la documentation
Entités	Création d'un modèle d'objet Génération de script DB Classes de base pour les entités	Fonctionnalités supplémentaires pour travailler avec des données
Dépôts	EntityManager Vues	Datamanager
Les services	Haricots de bureau Gestion des transactions Gestion des utilisateurs	Interface de persistance (et classe)
Contrôleurs	Contrôleurs REST natifs URL REST standard	Édition de services
Interface	Formes standard de travail avec les données	Styles et composants personnalisés

Bien sûr, Pet Clinic n'utilise pas toutes les fonctionnalités de CUBA, une liste complète des fonctionnalités de la plateforme peut être trouvée sur le site , vous y trouverez également des exemples de code pour résoudre les problèmes typiques qui surviennent lors du développement d'applications d'entreprise.

Mon opinion personnelle est que CUBA simplifie le développement du côté serveur de l'application et permet de gagner encore plus de temps sur le développement de l'interface utilisateur si vous utilisez des composants utilisateur standard et des capacités de style. Mais, même si vous avez besoin d'une interface utilisateur spéciale, il y aura toujours un gain de temps en raison du côté serveur standard.

Un plus! Y a-t-il des inconvénients?

Bien sûr, il n'y a pas de cadres parfaits. Ils ne sont pas critiques, mais au début, quand je viens de commencer à travailler avec CUBA, il y avait un certain inconfort. Mais la valeur de WTF / m n'était pas prohibitive.

• Pour la plateforme CUBA, il existe un IDE qui simplifie la création initiale d'un projet. Basculer entre studio et IDEA est un peu ennuyeux au début. La bonne nouvelle est qu'il existe une version bêta de CLI, vous n'avez pas besoin d'exécuter le studio pour générer la structure du projet, et aussi - la prochaine version de CUBA Studio sera un plugin Intellij IDEA. Plus de commutation.
  
• CUBA a plus de fichiers XML que l'application Spring Boot moyenne, c'est parce que l'initialisation du contexte dans CUBA se fait à sa manière. Maintenant que la lutte est en cours pour réduire la quantité de XML, nous nous tournons vers les annotations lorsque cela est possible.
  
• Il n'y a pas d'URL «lisibles» pour les formulaires d'interface utilisateur. Il est possible d'accéder aux formulaires via des liens vers des écrans , mais ils ne sont pas très conviviaux.
  
• Pour travailler avec des données, vous devez utiliser le DataManager, les vues et EntityManager, pas Spring JPA ou JDBC (mais ces API sont également disponibles si nécessaire).
  
• CUBA fonctionne mieux avec les bases de données relationnelles comme entrepôt de données. Comme pour NoSQL, vous devrez utiliser des bibliothèques d'accès pour ces référentiels et écrire votre propre couche de référentiel. Mais c'est la même quantité de travail que lors du développement d'une application sans CUBA, à mon avis.
  

Total

S'il y a une tâche de développement d'une application qui utilise une base de données relationnelle comme entrepôt de données et se concentre sur l'utilisation de données dans un format tabulaire, alors CUBA peut être un bon choix, car:

1. CUBA est transparent. Le code source est disponible, n'importe quelle méthode peut être déboguée.
   
2. CUBA est extensible (dans des limites connues, bien sûr). Vous pouvez hériter de presque n'importe quelle classe d'utilitaire et la glisser sur la plate-forme, créer votre propre API REST, utiliser votre framework préféré pour l'interface utilisateur. CUBA a été créé pour que vous puissiez facilement adapter des solutions pour n'importe quel client. Il y a un bon article sur l'extensibilité de la plateforme.
   
3. CUBA est le printemps. 80% de votre code serveur ne sera qu'une application Spring.
   
4. Démarrage rapide. Vous aurez une application à part entière avec un panneau d'administration après avoir créé la première entité et un écran pour travailler avec elle.
   
5. De nombreuses tâches de routine ont déjà été résolues dans la plateforme.
   

Ainsi, avec CUBA, vous pouvez gagner du temps sur l'écriture d'un code de "service" monotone et vous concentrer sur l'écriture de code pour résoudre des problèmes commerciaux. Et oui, chez Haulmont, nous utilisons nous-mêmes CUBA pour développer des produits en boîte et sur mesure.