Avantage Data Access Layer

Question

Au travail, j'essaie d'implémenter un modèle n-tier dans une grande application PHP déjà existante.

Je dois convaincre mes aînés puisqu'ils ne voient pas le point d'une couche supplémentaire de DA, en raison de la performance. Le code interroge maintenant le Db dans la logique métier et calcule dans la boucle tout en récupérant les données du jeu de résultats. Faible coût de performance.

J'ai essayé de les convaincre par des raisons évidentes: transparence («on peut lire SQL»), changement de base de données («ça n'arrivera pas»). Leur argument est que si cela est fait par une couche séparée, cela signifiera qu'un ensemble de données doit être créé et bouclé à nouveau dans la couche de gestion. Performance de coût. De plus, la création de ce modèle à n-tiers signifiera beaucoup de travail qui n'a pas de salaire «réel».

Est-ce un problème de performance, et donc une raison logique de dire non à une couche DA séparée?

Answer 1

Je pense que vous touchez un point important: SQL optimisé à la main sans une couche d'abstraction supplémentaire peut être plus rapide. Cependant, cela a un prix.

La question sera probablement: L'avantage de la vitesse supplémentaire l'emporte-t-il sur les avantages de la couche d'accès à la base de données, par ex. encapsulant les connaissances spécifiques SQL afin que les ingénieurs puissent se concentrer sur la logique métier (couche domaine).

Dans la plupart des cas, vous constaterez probablement que les performances d'une couche d'abstraction de base de données seront suffisantes si l'implémentation a été effectuée par un expert dans ce domaine. Si cela est fait correctement, le double tampon/bouclage peut être évité dans une large mesure.

Je soupçonne qu'il y a seulement une petite proportion d'application (je suppose qu'elle ne dépasse pas 20%) où les performances sont si importantes que la couche d'abstraction n'est pas une option. Mais il existe aussi une solution hybride: Utiliser la couche d'abstraction pour les 80% des modules où la flexibilité et la commodité l'emportent sur la vitesse et parlent directement à la base de données dans 20% des modules où la vitesse est critique. Je voterais probablement en faveur de la couche d'abstraction, puis j'optimiserais les performances là où c'est nécessaire (ce qui peut être réalisé autrement que par un dialogue direct avec la base de données).

Answer 2

couche d'accès aux données est une technologie dépassée comparer à la technologie actuelle, car il est trop compliqué & technologie scientifiquement non prouvée, il contrôlées après chacun et sql types de données dans une boucle while & valident les types de données, .net est confronté à des problèmes graves application de domaine comme l'exécution des codes d'un fichier de classe vers un autre fichier de classe prend plus de temps, car les assemblages .net ne sont pas étroitement couplés, preuve pour mon argument que nous pouvons exécuter Suse linux dans 256 Mo Ram d'une manière très fluide, mais pas windows 7 ou windows xp, De plus, net revendique la gestion automatique des mémos, ce qui n'est pas le cas, .net laisse beaucoup de mémoire inutilisée dans le tas, ce qui entraîne beaucoup de perte de performance dans DAP architechure, de plus les efforts dans DAL sont 95% plus la base de données en utilisant la procédure stockée, ne pas utiliser DAL, Au lieu de cela, utilisez les services Web WCF ou XML.