クライアント・サーバーモードでは、ロジックの実行にサーバー上でホストされているリソースが必要になることがよくあります。サーバー上でコードを実行するには、専用のプロジェクトメソッドやORDAデータモデル関数を記述するのが一般的です。
これにより、必ずしも正当化されないプロジェクトメソッドやORDAデータモデル関数が大量に生成される可能性があります。
4D 21 R3では、一部の シングルトンにおいて、 サーバー上で関数を実行できるようになりました。
コードの構成を改善する方法について、ぜひ読み進めてください!
デスクトップアプリケーションでは、接続されたすべての 4D クライアントで共有する必要があるデータを読み取ったり更新したりするため、コードの一部はサーバー上で実行する必要があります。たとえば、接続されたすべてのクライアント間でメモリ内のデータを共有するために、現在はサーバー上のストレージを使用しているかもしれません。
また、ロジックによっては、サーバーでホストされるリソース(データのクエリなど)が必要になる場合もあります。
サーバー上でコードを実行するために、以前は次のように記述していました:
- 「Execute on server」プロパティを有効にしたプロジェクトメソッド
- 「サーバー上で実行」コマンド
- ORDAデータモデル関数(デフォルトでサーバー上で実行されます)
現在、一部のシングルトンには 、常にサーバー上で実行される関数が含まれる場合があります。
共有およびセッションシングルトンの `server` キーワード
共有およびセッションシングルトンの関数は、現在 server キーワードをサポートするようになりました。
このserver キーワードを使用して関数を宣言すると、シングルトンが4D Client上でインスタンス化されている場合でも、その関数は常にサーバー上で実行されます。
例
以下の例では、Administration共有シングルトンが serverProcess activity()コマンドを実行する関数を定義しています。
このシングルトンは 4D クライアント上でインスタンス化され、そこから関数が呼び出されます。サーバーからアクティビティ(プロセス + セッション)を返します。
Administration共有シングルトン:
shared singleton Class constructor
// This function is executed on the server
server Function processActivity() : Object
return Process activity()
// This function is executed locally
Function localProcessActivity() : Object
return Process activity()
4Dクライアント上で実行されるコード:
var $localActivity; $serverActivity : Object
var $administration : cs.Administration
ASSERT(Application type()=4D Remote mode)
// The Administration singleton is instantiated on the 4D Client
$administration:=cs.Administration.me
// Get the processes running on the 4D client
$localActivity:=$administration.localProcessActivity()
ASSERT($localActivity.sessions=Null)
// Get the processes + sessions running on 4D Server
$serverActivity:=$administration.processActivity()
ASSERT($serverActivity.sessions.length>=1)
セッションシングルトンのさらなる活用
この文脈において、セッションシングルトンは大きな利点を提供します。セッションシングルトンは、セッション内のすべてのプロセスに対して一意の共有インスタンスを持ちます。
セッションシングルトンがサーバー上でロジックを実行できるようになれば、 Session コマンドの機能を効果的に拡張できます。
例
ユーザーをUsersテーブルに格納し、カスタム認証を実装する場合、この目的でセッションシングルトンを使用できます。
以下の例では、UserSessionセッションシングルトンが、サーバー上で実行される `checkUser() ` 関数を持っています。ユーザー ID は、セッション storage 共有オブジェクトに保存されます。
server Function checkUser($credentials : Object) : Boolean
var $user : cs.UsersEntity
var $result:=False
If ($credentials#Null)
$user:=ds.Users.query("Email === :1"; $credentials.identifier).first()
If (($user#Null) && (Verify password hash($credentials.password; $user.Password)))
Use (Session.storage)
Session.storage.userInfo:=New shared object("userId"; $user.ID)
End use
$result:=True
End if
End if
return $result
すべての 4D クライアントに現在のユーザーを提供するために、セッションシングルトンは、サーバーから取得した `user ` 計算プロパティを公開します。
session singleton Class constructor()
server Function get user() : cs.UsersEntity
return ds.Users.get(Session.storage.userInfo.userId)
添付のHDIを実行して、具体的な例を確認してください。次のステップは、関連するロジックを適切なクラスに配置してコードを整理することです。そして……4Dセッションの活用を今すぐ始めてみましょう!
現在、この投稿へのコメント機能は利用できません。