1

アプリケーションが成長するにつれて、複数の Web ページで多くのデータベース クエリを再利用していることに気付きました。

<cfstoredproc>現時点では、データベース データを必要とするすべてのページに含まれる多くのタグを持つ .CFM ファイルを使用して実行しました。私が行っているのは、これらのストアド プロシージャの実行を<cfif>タグでラップして、呼び出しページの名前をテストし、適切な<cfstoredproc>コード ブロックを実行することだけです。

私は何の専門家でもありませんが、これは私には適切ではありません。Web サイト全体のどの CFM ページでも共有できるように、すべてのデータベース クエリを正しく管理する方法がわかりません。たとえば、あるページには「GetUsers」ストアド プロシージャが必要で、別のページには「GetOrders」が必要な場合があります。

私は、すべての個別<cfstoredproc>または<cfquery>独自のメソッド/関数を保持する CFC の作成に着手しようとしています。例えば：

<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>

次に、メインの .CFM ページで、データを返すために必要なコンポーネントとメソッドを呼び出します。これは DB クエリ管理を実現する良い方法ですか?

4

3 に答える 3

4

データベースに関連しているという事実は、コードの繰り返しがあるという事実ほど関連性がありません。コードをより再利用可能にする取り組みにおいて、あなたは正しい方向に進んでいます。

クエリを cfc に入れる場合は、これをさらに一歩進めることを検討してください。常に呼び出すのではなく、Application.cfc の onApplicationStart メソッドを使用して、すべてのユーザーがすべてのページで使用できるアプリケーション変数を作成します。

もう 1 つの方法は、これらすべてのデータベース タグを .cfm ファイルに入れ、Application.cfc の onRequestStart メソッドに cfinclude を入れることです。

どちらの方法も機能します。そして、2 つのものを比較するときによくあることですが、それぞれに利点があります。

于 2013-11-17T14:57:10.293 に答える
1

次の 2 つの db テーブルを検討してください

ユーザー

UserID PrimaryKey 名 姓

安全

SecurityID PrimaryKey UserID ForeignKey パーミッション

すべてのデータベース テーブルには、作成、読み取り、更新、削除操作 (CRUD) があります。

CRUD 操作は複数の場所に存在する可能性があります

  1. <cfquery>タグの内側
  2. ストアド プロシージャの内部
  3. その他

問題は、すべての CRUD 操作が独自の方法でまとめられていることです。User オブジェクト ( ) の作成を検討してくださいuser.cfc。

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

セキュリティはユーザー管理の一部なので、オブジェクトは db テーブルと 1 対 1 で一致しますか? ORM のような一部の環境では答えはイエスですが、そうでない環境もあります。

セキュリティがユーザー管理の一部であると考える場合、次のようになりますuser.cfc。

<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>

一日の終わりには、必要なオブジェクト ( *.cfc) がテーブルよりもはるかに少ないことに気付くかもしれません。

OK、これであなたはそれuser.cfcで何をしますか? さまざまな方法でアプリの残りの部分にアタッチできます

  • application.User = 新しいユーザー();
  • session.User = 新しいユーザー();
  • request.User = 新しいユーザー();

これらのそれぞれは、次から非常にです。どちらが適切かを判断する前に、メンバー データと、それをどのくらいの期間使用するかを検討する必要があります。

<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>

CRUD 操作はUserID、すべての操作に対して同じ操作を行う可能性があります。レコードを更新した後、頻繁にそれを読むことに気付くかもしれません。どちらとUserID対話しているかを常に述べるのではなく、一度設定して、すべての機能が同じ機能を使用するようにしたい場合があります。

OK、では、それらを使用する場所に戻りましょう

アプリケーション.ユーザー

Userシステム全体で1 つのオブジェクトのみが存在します。サイトにリクエストが来ると作成されます。このオブジェクトは、リクエストごとに共有されます。ここにオブジェクトをアタッチするuserと、すべてのリクエストが同じユーザーを参照することになります。

session.UserUser外の世界では、特定のエンドユーザーに対して 1 つのオブジェクトが存在します。他のすべてのエンドユーザーから分離されます。userこれは、各エンド ユーザーが自分のサイトを見ていて、サイトをクリックしても同じサイトを見ていることを示唆しています。user

request.Userリクエストごとに 1 つのUserオブジェクトが存在します。特定のリクエストに対してのみ存在し、その後破棄されます。これは、このリクエストでは特定のものを見ることは意味があることを示唆していUserますが、次のものはまったく異なるか、ユーザーについてでさえない可能性があります。

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

最終的には、DB インタラクションをバンドルする方法と、これらのバンドルされたアクションを一緒に保持する期間を決定する必要があります。

于 2013-11-17T19:45:34.170 に答える