Votre principe directeur devrait être de ne pas vous répéter :
En génie logiciel, Don't Repeat Yourself (DRY) est un principe de développement logiciel visant à réduire la répétition d'informations de toutes sortes, particulièrement utile dans les architectures multi-niveaux. Le principe DRY est énoncé comme «chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité au sein d'un système».
L'ORM est essentiellement une couche supplémentaire (ou un niveau si vous préférez), reposant confortablement entre votre application et votre (vos) stockage (s) de données. Vos contraintes doivent être en un seul endroit, et un seul endroit, que ce soit l'ORM ou le stockage de données, sinon assez tôt vous finirez par en conserver différentes versions. Vous ne voulez vraiment pas faire ça.
Cependant, dans la pratique, la plupart des ORM à moitié décents génèrent automatiquement une grande partie de vos modèles à partir de votre schéma de données. Bien qu'il y ait toujours duplication, les chances d'enfer de maintenance sont minimes puisque le code ORM dupliqué est généré suivant le même modèle à chaque fois. Il serait idéal de ne pas avoir de code en double, mais les contraintes générées automatiquement sont la prochaine meilleure chose.
De plus, avoir vos contraintes au même endroit ne signifie pas nécessairement que vous devriez avoir toutes vos contraintes au même endroit. Certaines, comme les contraintes d'intégrité référentielle, peuvent être plus adaptées au stockage de données (mais peuvent être perdues si vous passez à un autre stockage de données), et certaines, principalement celles qui concernent une logique métier complexe, conviennent mieux à votre ORM. Il serait préférable d'avoir toutes vos pommes dans le même panier, mais…
Les échecs
Vous mentionnez l'échec de l'ORM. Cela n'a absolument rien à voir avec votre question, votre application doit considérer l'ORM et le (s) stockage (s) de données comme une seule entité. S'il échoue, il échoue, contourner l'ORM pour parler directement au stockage de données n'est pas une bonne idée.
Contourner l'ORM pour autre chose
Ce n'est pas non plus une bonne idée. Cependant, cela peut se produire pour diverses raisons:
Parties héritées de l'application qui ont été créées avant l'introduction de l'ORM.
C'est difficile, et c'est exactement la situation à laquelle je fais face en ce moment , d'où ma répétition constante de «l'enfer de la maintenance». Soit vous continuez à maintenir les parties non ORM, soit vous les réécrivez pour utiliser l'ORM. La deuxième option pourrait avoir plus de sens au départ, mais c'est une décision qui est uniquement basée sur ce que font exactement ces parties de votre application et sur la valeur d'une réécriture complète à long terme.
Essayez de changer une clé dans une table MySQL de 2 * 10 ^ 8 lignes mal conçue (sans temps d'arrêt) et vous comprendrez d'où je viens.
Parties non héritées de l'application qui doivent absolument parler directement au stockage de données:
Encore plus délicat. Les ORM sont des outils sophistiqués, et ils s'occupent de presque tout, mais parfois ils gênent ou sont même absolument inutiles. Le mot à la mode (vraiment la phrase à la mode) est une non-correspondance d'impédance relationnelle-objet , il suffit de dire qu'il n'est techniquement pas possible pour votre ORM de faire tout ce que fait votre base de données relationnelle, et pour certaines choses qu'ils font, il y a une pénalité de performance significative.
commentaires
Du point de vue de l'intégrité des données, les contraintes DOIVENT être sur la base de données et DEVRAIENT être sur l'application. Que se passe-t-il si votre application est accessible à partir d'une application Web et d'une application de bureau, d'une application mobile ou d'un service Web? - Luiz Damim
C'est là que l'ajout d'une couche supplémentaire serait extrêmement utile, et si nous parlons d'une application Web, j'irais avec une API REST. Une conception trop simpliste pour cela serait:
L'ORM se situerait entre l'API et les stockages de données, et tout ce qui se trouve derrière l'API (y compris celle-ci) serait considéré comme une entité unique issue des différentes applications.