Cliente-servidor: una nueva forma de ejecutar la lógica en el servidor

En el modo cliente-servidor, la lógica suele requerir recursos alojados en el servidor. Para ejecutar código en el servidor, se suele escribir métodos de proyecto dedicados o funciones del modelo de datos ORDA.

Esto puede dar lugar a un gran número de métodos de proyecto o de funciones del modelo de datos ORDA que no siempre están justificados. 

Con 4D 21 R3, algunos singletons ahora pueden tener funciones que se ejecutan en el servidor. 

Siga leyendo para aprender a mejorar la organización de su código.

HDI_ServerKeyword_Singletons

En sus aplicaciones de escritorio, ciertas partes del código deben ejecutarse en el servidor porque leen o actualizan datos que deben ser compartidos por todos los clientes 4D conectados. Por ejemplo, para compartir datos en memoria entre todos los clientes conectados, actualmente puede utilizar el almacenamiento del servidor. 

Su lógica también puede requerir recursos alojados en el servidor (por ejemplo, consultar datos).

Para ejecutar código en el servidor, solía escribir:

• un método de proyecto con la propiedad Ejecutar en el servidor activada
• un comando Execute on server
• una función del modelo de datos ORDA (que se ejecuta por defecto en el servidor)

Ahora, algunos singletons pueden tener funciones que siempre se ejecutan en el servidor.

 

La palabra clave «server» para los singletons compartidos y de sesión

Las funciones de los singletons compartidos y de sesión ahora admiten el server.

Cuando una función se declara con esta palabra clave server, siempre se ejecuta en el servidor, incluso si el singleton se instancia en un 4D Client.

Ejemplo

En el ejemplo siguiente, el singleton compartido Administration define una función server que ejecuta el comando Process activity(). 

Este singleton se instancia en un 4D Client, y la función se invoca desde allí. Devuelve la actividad del servidor (procesos + sesiones).

El singleton compartido 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()

Código que se ejecuta en el cliente 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)

Profundizando en el singleton de sesión

En este contexto, el singleton de sesión ofrece una ventaja importante. Un singleton de sesión tiene una instancia compartida única para todos los procesos en una sesión.

En cuanto un singleton de sesión puede ejecutar lógica en el servidor, puede ampliar de forma efectiva las capacidades del comando ` Session `.

Ejemplo

Si almacena a sus usuarios en una tabla Users e implementa una autenticación personalizada, puede utilizar un singleton de sesión para este fin.

En el ejemplo siguiente, el singleton de sesión UserSession tiene una función checkUser() que se ejecuta en el servidor. El ID de usuario se almacena en el objeto compartido de la sesión 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

Para ofrecer al usuario actual a todos los clientes 4D, el singleton de sesión expone una propiedad calculada user recuperada del servidor.

session singleton Class constructor()

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

Ejecute el HDI adjunto para explorar ejemplos concretos. El siguiente paso es organizar mejor su código colocando la lógica relevante en la clase adecuada y… ¡No espere más para empezar a trabajar con sesiones 4D!