La gestion des requêtes de base de données qui sont utilisés sur l'ensemble du site

Question

Que ma demande a bien grandi, j'ai remarqué que je suis la réutilisation de beaucoup de requêtes de base de données à travers de multiples pages web.

Au moment où je l'ai fait à l'aide d'un .Fichier CFM qui a de nombreuses <cfstoredproc> les balises qui est inclus sur chaque page de données de base de données.Tout ce que je suis en train de faire est de mettre ces exécutions de procédures stockées dans une <cfif> tag les tests quel est le nom de la page appelant est et à l'exécuter approprié <cfstoredproc> bloc de code.

Je ne suis pas un expert en quoi que ce soit, mais cela ne se sent pas le droit de me.Je ne sais pas comment faire pour gérer tous mes requêtes de base de données correctement de sorte qu'ils peuvent être partagées à l'échelle de toute page CFM dans l'ensemble du site.Par exemple, une page pourrait avoir besoin de l' "GetUsers" procédure stockée et une autre page peut-être besoin "GetOrders".

Je suis sur le point de s'embarquer sur la création d'un CFC qui détient toutes les <cfstoredproc> ou <cfquery> dans sa propre méthode/fonction.E. g.:

<cfcomponent name="DBQueries" hint="Everything for DB retrieval">
 <cffunction name="GetUsers" returntype="query">
   <cfstoredproc procedure="GetUsers">
   <cfprocresult name="rsUsers">
   </cfstoredproc>
   <cfreturn rsUsers>
 </cffunction>
.....
 <cffunction name="DBQuery100">
   <cfstoredproc procedure="GetSomething" returntype="query">
   <cfprocresult name="rsSomething">
   </cfstoredproc>
   <cfreturn rsSomething>
 </cffunction>
</cfcomponent>

Puis, sur un axe principal .CFM page, je vais appeler le composant et la méthode nécessaire pour renvoyer les données.Est-ce un bon moyen pour y parvenir DB de gestion des requêtes?

Answer 1

Considérons la suite de deux tables db

L'utilisateur

UserID PrimaryKey prénom lastname

Sécurité

SecurityID PrimaryKey UserID ForeignKey L'autorisation

Toutes les tables de base de données Create, Read, Update, Delete les opérations CRUD ()

Les opérations CRUD peut exister dans plusieurs endroits

1. À l'intérieur de <cfquery> tags
2. À l'intérieur de procédures Stockées
3. D'autres

Le truc, c'est toutes les opérations CRUD appartiennent tous deux à leur manière.Envisager de faire un objet Utilisateur (user.cfc).

<cfcomponent>
   <cffunction name="create"></cffunction>
   <cffunction name="read"></cffunction>
   <cffunction name="update"></cffunction>
   <cffunction name="delete"></cffunction>
 </cfcomponent> 

La sécurité est une partie de la gestion des utilisateurs, est l'objet d'un un à un match à la table db?Dans certains milieux, comme les ORM, la réponse est oui, dans d'autres non.

Si vous considérez la sécurité d'une part de l'utilisateur gestion, vos user.cfc pourrait ressembler à ceci

<cfcomponent>
   <cffunction name="create"></cffunction>
   <cffunction name="read" hint="Read will also read security info"></cffunction>
   <cffunction name="update" hint="Perhaps this can update security too"></cffunction>
   <cffunction name="delete" hint="Delete will also delete security info"></cffunction>

   <cffunction name="create_security"></cffunction>
   <cffunction name="read_secrity" hint="This may not even be needed"></cffunction>
   <cffunction name="update_security"></cffunction>       
   <cffunction name="delete_security" hint="This may not even be needed"></cffunction>
</cfcomponent> 

À la fin de la journée, vous pouvez trouver que vous avez besoin de beaucoup moins d'objets (*.cfcs) que les tables.

OK, maintenant vous avez vous user.cfc que faites-vous avec elle?Il peut être attaché à vous le reste de votre application de différentes manières

• application.Utilisateur = new utilisateur();
• session.Utilisateur = new utilisateur();
• demande.Utilisateur = new utilisateur();

Chacun de ces est très partir de la prochaine.Avant d'aller en bas de la route de ce qui est approprié, nous devons examiner les données sur les membres, et combien de temps nous voulons autour de.

<cfcomponent>
   <cfset this.userid = ""><!--- This always points to the user I want to interact with --->

   <cffunction name="create"></cffunction>
   <cffunction name="read"></cffunction>
   <cffunction name="update"></cffunction>
   <cffunction name="delete"></cffunction>
 </cfcomponent> 

Il est probable que vos opérations CRUD vont interagir avec la même UserID pour l'ensemble de leurs opérations.Vous pouvez constater qu'après la mise à jour d'un enregistrement, vous allez souvent lire il.Plutôt que de toujours déclarant qui UserID vous interagissez avec, vous pouvez le configurer une fois, et de disposer de toutes les fonctions utilisent le même.

OK, maintenant nous allons revenir à où vous serez en utilisant

application.L'utilisateur

Un seul User l'objet existe dans le l'ensemble du système.Il sera créé lors de la demande sur le site.Cet objet sera partagé pour chaque demande.Si vous fixez votre user l'objet ici, qui suggère que toutes les demandes seront à la recherche dans le même utilisateur.

session.L'utilisateur Un User objet existera pour un utilisateur final dans le monde extérieur.Il sera séparé de tous les autres utilisateurs finals.Ceci suggère que chaque utilisateur final sera à la recherche à leurs propres user ET que même si ils cliquent à travers le site, elles seront toujours les mêmes user

demande.L'utilisateur Un User objet existera par demande.Il existe uniquement pour une demande particulière, et ensuite être mis au rebut.Ceci suggère que le fait de regarder à particulier User est significative sur cette demande, mais la prochaine peut être tout à fait différent, ou peut-être même pas sur les utilisateurs.

~~~~~~~~~~~~~~~

À la fin de la journée, vous aurez besoin de décider comment regrouper vos DB interactions, et combien de temps vous permettra de garder ceux regroupés ensemble

Answer 2

Le fait que la base de données relative n'est pas aussi pertinent que le fait que vous avez la répétition de code.Vous êtes sur la bonne voie dans votre effort pour rendre le code plus ré-utilisable.

Si vous mettez vos requêtes dans un cfc, vous pourriez envisager de prendre un peu plus loin.Au lieu d'appeler tout le temps, utilisez la onApplicationStart méthode de votre Application.cfc pour créer une variable d'application qui est disponible à tous les utilisateurs sur toutes les pages.

Une autre approche est de mettre toutes ces balises de base de données dans un .fichier de gestion de trésorerie et de mettre un cfinclude dans le onRequestStart méthode de votre Application.le cfc.

Les deux méthodes de travail.Et, comme c'est presque toujours le cas lorsque vous comparez deux choses, chacun a des avantages sur les autres.

Answer 3

Je voudrais avoir un modèle par table.

de là, vous avez toutes les requêtes que jamais quoi que ce soit à la table

Disons que la table des Utilisateurs

Les utilisateurs.cfc

aurait toutes les méthodes qui renvoient des requêtes

getUsers - retour alll utilisateurs

getUserById - pourrait être un paramater sur la première fonction.

Puis, quand vous avez besoin de travailler sur quelque chose de commandes est en cours de mise à jour il y a un seul endroit à regarder.

Je reçois les résultats comme ceci

<cfset users = new model.Users().getUsers() />

ou j'ai utiliser le script

users = new model.Users().getUsers();

Et si votre vraiment courageux, essayez de faire toutes les requêtes dans le script aussi.

Une dernière chose à considérer si les données ne changent pas, le cache de la requête.

Des choses comme OrderType ou similaire, vous obtiendrez un grand nombre d'en profiter plutôt que de répéter la requête et plus.