est-il nécessaire de refactoriser une grande couche d'accès aux données

Question

J'ai une couche d'accès aux données qui extrait le reste de l'application de la technologie de persistance. À l'heure actuelle, l'implémentation est un serveur SQL, mais cela pourrait changer. Quoi qu'il en soit, je trouve que cette classe d'accès aux données principales devient plus grande et plus grande à mesure que mes tables grandissent (environ 40 tables maintenant). L'interface de cette couche d'accès aux données est une question que vous pouvez obtenir des données sur

public interface IOrderRepository 
{ 
     Customer[] GetCustomerForOrder(int orderID); 
     Order[] GetCustomerOrders(int customerID); 
     Product[] GetProductList(int orderID); 
     Order[] GetallCustomersOrders(int customerID); 
     etc . . . 
} 

la mise en œuvre derrière c'est SQL de base stockées procs pour exécuter les requêtes appropriées et le retour des résultats dans les collections typées

cette volonté continuer à grandir et à grandir. C'est assez facile à maintenir car il n'y a pas vraiment de rupture de responsabilité mais la classe compte maintenant plus de 2000 lignes de code. Donc, la question est, en raison de la taille de classe sûre (et pas de véritable couplage conceptuel), si cela se décomposer et si oui sur quelle dimension ou niveau d'abstraction.

Answer 1

Absolument refactor. 2000 lignes est énorme.

Je commencerais par le décomposer par type de retour. Ainsi, vous obtiendrez une classe pour accéder aux produits, une pour les commandes, une pour les clients et ainsi de suite.

Pour chaque classe, l'ensemble de colonnes sélectionné devrait probablement être le même, de sorte qu'il pourrait être refactorisé en une seule variable/méthode comme l'extraction des valeurs SQL dans les objets.

Aussi l'appel réel à la procédure stockée, y compris la journalisation et la gestion des exceptions pourrait et devrait aller dans une classe distincte.

BTW vous avez une violation de la responsabilité unique.Selon votre description votre bonne classe a maintenant les responsabilités suivantes:

• créer des instructions SQL pour interroger une table (environ 40 fois)
• hydratant les résultats des appels à des procédures stockées
• appel de procédures stockées

Et je suppose - exploitation forestière - gestion des exceptions

Answer 2

Je pense qu'il devrait être factorisé juste à cause de la taille. Il y a toujours beaucoup de dimension sur laquelle vous pouvez le décomposer. Puisque la panne est simplement de rendre le code plus gérable, ne choisissez pas une dimension trop complexe - gardez-la simple pour qu'il soit facile de deviner dans quelle classe/interface une fonction donnée sera trouvée.

Answer 3

Il s'agit d'un problème difficile à résoudre ... en premier lieu, divisez-le en plusieurs fichiers et classes, et en second lieu, divisez les objets métier de l'objet technologique; vous pouvez écrire vos objets métier en termes d'interface de base de données (que vous écrivez vous-même). et à l'avenir, si vous changez de DB, tout ce dont vous avez besoin est de remplacer l'objet technologique. Malheureusement vous ne pouvez pas vraiment échapper à la croissance du schéma de données, vous obtiendrez plus de procédures stockées, plus de tables et plus d'objets métier. Cependant, essayez votre niveau mieux dirigé pour modifier plutôt que d'ajouter de nouvelles tables.

Je suggère d'essayer de former un workflow de coupler les éléments ensemble comme ressources. J'entends par là non pas des dépendances physiques mais une documentation qui vous permettra de relier tous les trois types d'éléments dans votre couche de données - par exemple, vous pouvez commencer à ajouter des annotations dans les commentaires de vos objets métier pour spécifier les procédures stockées et les tables ça dépend de. Vous pouvez le faire pour les procédures stockées même dans les tables de SQL Server (le schéma a un champ de description pour les tables). Ces conseils devraient vous aider à garder une vue d'ensemble.

Answer 4

Considérons un DAO générique si votre langue les héberge. Vous pourriez également penser à la requête par l'exemple pour réduire le nombre d'appels requis.