Client-Server – Eine neue Methode zur Ausführung von Logik auf dem Server

Im Client-Server-Modus benötigt Ihre Logik häufig Ressourcen, die auf dem Server gehostet werden. Um Code auf dem Server auszuführen, sind Sie es gewohnt, spezielle Projektmethoden oder ORDA-Datenmodellfunktionen zu schreiben.

Dies kann zu einer großen Anzahl von Projektmethoden oder ORDA-Datenmodellfunktionen führen, die nicht immer gerechtfertigt sind. 

Mit 4D 21 R3 können nun bei einigen Singletons Funktionen auf dem Server ausgeführt werden. 

Lesen Sie weiter, um zu erfahren, wie Sie Ihre Code-Organisation verbessern können!

HDI_ServerKeyword_Singletons

In Ihren Desktop-Anwendungen müssen bestimmte Teile des Codes auf dem Server ausgeführt werden, da sie Daten lesen oder aktualisieren, die von allen verbundenen 4D-Clients gemeinsam genutzt werden müssen. Um beispielsweise Daten im Speicher für alle verbundenen Clients freizugeben, nutzen Sie derzeit möglicherweise den Speicher auf dem Server. 

Ihre Logik erfordert möglicherweise auch vom Server gehostete Ressourcen (z. B. das Abfragen von Daten).

Um Code auf dem Server auszuführen, haben Sie bisher Folgendes geschrieben:

• eine Projektmethode mit der aktivierten Eigenschaft „Auf Server ausführen“
• einen Befehl „Auf Server ausführen “
• eine ORDA-Datenmodellfunktion (die standardmäßig auf dem Server ausgeführt wird)

Nun können einige Singletons Funktionen haben, die immer auf dem Server ausgeführt werden.

Das Schlüsselwort „server“ für Shared- und Session-Singletons

Funktionen in Shared- und Session-Singletons unterstützen nun das server Schlüsselwort.

Wenn eine Funktion mit diesem Schlüsselwort „ server “ deklariert wird, wird sie immer auf dem Server ausgeführt, selbst wenn das Singleton auf einem 4D-Client instanziiert wird.

Beispiel

Im folgenden Beispiel definiert das gemeinsam genutzte Singleton „Administration“ eine server Funktion, die den Befehl Process activity() ausführt. 

Dieses Singleton wird auf einem 4D-Client instanziiert, und die Funktion wird von dort aus aufgerufen. Sie gibt die Aktivität vom Server zurück (Prozesse + Sitzungen).

Das gemeinsam genutzte Singleton „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()

Auf dem 4D-Client ausgeführter Code:

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)

Weiterführende Informationen zum Session-Singleton

In diesem Zusammenhang bietet das Session-Singleton einen großen Vorteil. Ein Session-Singleton verfügt über eine einzige gemeinsame Instanz für alle Prozesse innerhalb einer Sitzung.

Sobald ein Session-Singleton Logik auf dem Server ausführen kann, erweitert es effektiv die Möglichkeiten des Befehls „ Session “.

Beispiel

Wenn Sie Ihre Benutzer in einer Users-Tabelle speichern und eine benutzerdefinierte Authentifizierung implementieren, können Sie zu diesem Zweck ein Session-Singleton verwenden.

Im folgenden Beispiel verfügt das Session-Singleton „UserSession“ über eine Funktion „ checkUser() “, die auf dem Server ausgeführt wird. Die Benutzer-ID wird im gemeinsamen Objekt der Sitzung gespeichert 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

Um allen 4D-Clients den aktuellen Benutzer bereitzustellen, stellt das Session-Singleton eine berechnete Eigenschaft „ user “ bereit, die vom Server abgerufen wird.

session singleton Class constructor()

server Function get user() : cs.UsersEntity
	return ds.Users.get(Session.storage.userInfo.userId)

Führen Sie die beigefügte HDI aus, um konkrete Beispiele zu erkunden. Der nächste Schritt besteht darin, Ihren Code besser zu organisieren, indem Sie die relevante Logik in die entsprechende Klasse verschieben und … zögern Sie nicht, mit 4D-Sitzungen zu arbeiten!