Je travaille dans une entreprise qui n'utilise que des procédures stockées pour tous les accès aux données, ce qui rend très ennuyeux de garder nos bases de données locales synchronisées, car à chaque validation, nous devons exécuter de nouveaux processus. J'ai utilisé des ORM de base dans le passé et je trouve l'expérience bien meilleure et plus propre. Je voudrais suggérer au responsable du développement et au reste de l'équipe que nous envisagions d'utiliser un ORM quelconque pour un développement futur (le reste de l'équipe ne connaît que les procédures stockées et n'a jamais utilisé autre chose). L'architecture actuelle est .NET 3.5 écrite comme .NET 1.1, avec des "classes divines" qui utilisent une implémentation étrange d'ActiveRecord et retournent des DataSets non typés qui sont bouclés dans des fichiers code-behind - les classes fonctionnent quelque chose comme ceci:
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...
Il n'y a pratiquement aucune application de modèles de conception. Il n'y a aucun test (personne d'autre ne sait comment écrire des tests unitaires, et les tests sont effectués en chargeant manuellement le site Web et en fouillant). En parcourant notre base de données, nous avons: 199 tables, 13 vues, 926 procédures stockées et 93 fonctions. Une trentaine de tables sont utilisées pour des travaux par lots ou des objets externes, les autres sont utilisés dans notre application principale.
Vaut-il même la peine de poursuivre une approche différente dans ce scénario? Je parle d'avancer uniquement car nous ne sommes pas autorisés à refactoriser le code existant car "cela fonctionne" donc nous ne pouvons pas changer les classes existantes pour utiliser un ORM, mais je ne sais pas à quelle fréquence nous ajoutons de nouveaux modules à la place d'ajouter / de réparer les modules actuels, donc je ne sais pas si un ORM est la bonne approche (trop investi dans les procédures stockées et les DataSets). Si c'est le bon choix, comment dois-je présenter le cas pour en utiliser un? Sur le haut de ma tête, les seuls avantages auxquels je peux penser sont d'avoir un code plus propre (bien que ce ne soit peut-être pas, car l'architecture actuelle n'est pas t construit avec des ORM à l'esprit, donc nous serions fondamentalement en train de truquer des ORM sur des modules futurs mais les anciens utiliseraient toujours les DataSets) et moins de tracas pour se rappeler quels scripts de procédure ont été exécutés et lesquels doivent être exécutés, etc. mais c'est tout, et je ne sais pas à quel point ce serait un argument convaincant. La maintenabilité est une autre préoccupation, mais personne, sauf moi, ne semble s'inquiéter.