Dans l'application parfaite, chaque règle commerciale n'existerait qu'une seule fois.
Je travaille pour un magasin qui applique autant que possible les règles commerciales dans la base de données. Dans de nombreux cas, pour obtenir une meilleure expérience utilisateur, nous effectuons des validations identiques du côté du client. Pas très Dry . Être un Spot puriste, je déteste ceci.
À l'autre extrémité du spectre, certains magasins créent des bases de données stupides (la communauté des rails se penche dans cette direction) et reléguez la logique commerciale à un niveau séparé. Mais même avec cette balle, une logique de validation finit par un côté client répété.
Pour compliquer davantage la matière, je comprends pourquoi la base de données devrait être une forteresse et donc je conviens que les validations soient appliquées / répétées à la base de données.
Essayer d'appliquer des validations à un endroit n'est pas facile à la lumière des préoccupations contradictoires - rester au sec, conserver la base de données une forteresse et fournir une bonne expérience utilisateur. J'ai Une idée pour surmonter ce problème , mais j'imagine qu'il y en a mieux.
Pouvons-nous équilibrer ces préoccupations conflictuelles de manière sec?
6 Réponses :
Quiconque n'applique pas les règles commerciales requises dans la base de données où elles appartiennent vont avoir de mauvaises données, aussi simples que cela. L'intégrité des données est le travail Les données vivront sur l'application depuis longtemps dans de nombreux cas. Vous perdez les règles lorsque cela se produit aussi.
Le moyen facile d'avoir Tous Ces problèmes consiste à briser l'architecture, à contourner la couche de règle de gestion qui a été mise en dehors de la base de données. Le moyen facile d'empêcher ces problèmes est de rendre un accès "direct" aux motifs de la base de données de licenciement.
Fortement en désaccord. Je n'importe pas un million d'objectifs un enregistrement à la fois en utilisant l'application. Je ne devrais pas non plus faire une mise à jour de données majeure de cette façon.
Vous proposez d'importer un million d'enregistrements avec une validation complète des données effectuée dans la base de données? Comment ça marche? Procédures stockées? N'est-ce pas terriblement lent? Ou une étape de validation doit-elle être exécutée d'abord avant de charger? Je ne comprends pas ce que vous proposez.
"Les bases de données sont affectées par de nombreuses autres sources que l'application" Toutes les autres "sources" qui affectent votre base de données ont besoin de passer par la couche d'entreprise de l'application. Si vous avez plusieurs applications (avec différentes couches d'entreprise) accédant à la même base de données, vous le faites mal.
Le cadre du manuel-View-contrôleur est un moyen de résoudre ce problème. La communauté des rails utilise un concept similaire ...
L'idée de base est que toutes les logiques commerciales sont traitées dans le contrôleur et où les règles doivent être appliquées dans la vue ou le modèle, elles sont transmises par le contrôleur.
En chemin, une séparation propre des préoccupations où toute la logique commerciale existe dans un seul centre de base est une fantaisie utopique qui est difficile à maintenir
Vous ne pouvez pas voir pourquoi.
gérer toute la logique d'entreprise dans un niveau séparé (dans les rails Les modèles abriteraient "la plupart" de cela)
correct. Django fait cela aussi.
Certaines logiques d'entreprise finissent par se débarrasser dans d'autres endroits (dans des rails, il pourrait se déverser dans les contrôleurs
pas vraiment. La logique commerciale peut - et devrait - être dans le modèle de modèle. Certaines d'entre elles seront codées comme méthodes de classes, de bibliothèques et d'autres faisceaux de logique qui peuvent être utilisées ailleurs. Django le fait-il avec des objets de forme qui valident l'entrée. Celles-ci proviennent du modèle, mais sont utilisées dans le cadre du code HTML frontal ainsi que des charges en vrac.
Il n'y a aucune raison pour que la logique commerciale soit définie ailleurs. Il peut être utilisé dans d'autres niveaux, mais il devrait être défini dans le modèle.
Utilisez une couche ORM pour générer le SQL du modèle. Tout au même endroit.
[Base de données] Construit sur des contraintes qui la causent de rejeter les données incorrectes
Je pense que c'est une erreur erronée le poste. Il est indiqué "un modèle de données solide" "," Rejeter des données n'appartenant pas et empêcher les relations qui n'ont pas de sens ". Ce sont une intégrité référentielle déclarative simple.
Une couche ORM peut générer ceci à partir du modèle.
Eh bien, en général, les règles commerciales sont beaucoup plus que des ensembles de contraintes, il est donc évident que toutes les règles commerciales ne peuvent pas être placées dans la base de données. D'autre part, HLGEM a souligné qu'il est naïf de s'attendre à ce que l'application gère toute la validation des données: je peux confirmer cela de l'expérience.
Je ne pense pas qu'il y ait une bonne façon de mettre toutes les règles de l'entreprise au même endroit et de les faire appliquer sur le client, le côté serveur et la base de données. Je vis avec des règles d'entreprise au niveau de l'entité (comme Hibernate les recréche au niveau de la base de données) et les règles restantes au niveau de service.
Les préoccupations de la base de données-A-A-A-A-A-A-Fortress et de la vérité monocommande sont une seule et même chose. Ils ne sont pas mutuellement exclusifs. Et donc il n'y a pas besoin de quoi de sorte de "équilibrer".
Ce que vous appelez "la base de données-as-a-forteress" est vraiment le seul moyen possible d'implémenter un point de vérité unique.
"Base de données-AS-A-FORTRESS" est une bonne chose. Cela signifie que la base de données oblige toute personne à rester à l'écart qui ne veut pas se conformer (à la vérité que la base de données est censée adhérer à). Que tant de gens trouvent qu'un problème (plutôt que la solution que c'est vraiment), dit tout sur la manière dont la majorité des utilisateurs de la base de données pensent sur l'importance de la "vérité" (par opposition à "j'ai Cette charge de merde que j'ai besoin de persister, et je veux juste que la base de données fasse cela malgré toute règle d'entreprise, ce qui soit de ce jour. ").
Base de données-AS-A-FORTRESS est un non-sens pour des bases de données relationnelles. Vous avez besoin d'une oodb pour ça.
Rangez-les dans une boîte tupperware remplie de riz. Attendez Désolé, nous avons fait les blagues.