Je viens de commencer un nouveau travail de développeur de base de données pour une entreprise de taille moyenne à petite basée sur la technologie Microsoft. J'ai remarqué très tôt à quel point les pratiques s'écartent de ce que j'ai appris à l'école en ce qui concerne les meilleures pratiques, les modèles de conception, les tests et la gestion de projet.
Ce qui me dérange le plus, c'est la façon dont notre développeur de base de données principal (désormais appelé "John") conserve le schéma du modèle dans la base de données! Nous le faisons en ayant 3 tables "magiques"; un pour les schémas de base de données, un pour les tables et un pour les colonnes.
L'insertion d'un enregistrement dans la table " Tables " génère (via un déclencheur de base de données), la table réelle correspondante. L'insertion d'une ligne dans la table " Lignes " met à jour la table référencée avec cette ligne. Ceux-ci sont à leur tour lus par son programme C # maison pour générer des modèles C #, qui sont utilisés par les développeurs frontaux pour les contrôleurs et vers l'extérieur.
En dehors de cela, la plupart du développement se fait selon le framework ASP.NET MVC .
Je vois quelques défauts avec cette approche:
- Nous avons besoin de lui pour maintenir l'ORM, et il a rarement le temps de le faire (la sécurité d'emploi est bonne!)
- Les déclencheurs des tables "Tables" et "Lignes" sont défectueux. Ils ne prennent pas en charge les mises à jour de table, ni les contraintes de vérification ni les fonctionnalités plus "avancées". Bien que nous puissions certainement les améliorer, je ne sais pas encore si c'est la voie à suivre.
- Garder la logique programmatique dans la base de données semble étrange et restrictif (bien qu'il soit possible d'étendre ses modèles via C #).
- Son générateur de modèle C # doit être exécuté manuellement par l'une des 3 personnes (dont je fais partie) et n'est pas encore suffisamment mature pour être inclus dans un processus de construction automatisé.
Plusieurs personnes ont suggéré d'introduire progressivement un produit véritable et testé comme Entity Framework , mais il le rejette, affirmant que le maintien de la logique métier dans la couche de code ne convient qu'aux applications à petite échelle et aux projets d'amorçage pour les startups.
Ce message mène à quelque chose qui pourrait ressembler à une discussion d'opinion, mais ce n'est pas mon intention. Je veux juste des éclaircissements sur notre approche architecturale.
La conservation des modèles de domaine dans la base de données peut-elle être une solution durable pour une entreprise en croissance?