2009-07-28 17 views
5

Soy nuevo en ASP clásico y necesito codificar una aplicación web en asp clásico porque el cliente quiere que esté en asp clásico. ! :(Objetos clásicos de la tienda ASP en el objeto de sesión

De todas formas aquí está mi pregunta: ¿

Cuando tengo un objeto de un llamado persona de clase:

Class Person 
Private m_sFirstName 

Public Property Get firstName 
firstName = m_sFirstName 
End Property 

Public Property Let firstName(value) 
    m_sFirstName = value 
End Property 

End Class 


set aPerson = new Person 
Person.firstName = "Danny" 

set Session("somePerson") = aPerson 

Hasta aquí todo bien ...

En la siguiente solicitud, intento leer la sesión var como:

If IsObject(Session("aPerson")) = true Then 
    set mySessionPerson = Session("aPerson") 

     Response.Write(TypeName(myTest)) // will output "Person" 
     Response.Write(mySessionPerson.firstName) // will output "Object doesn't support this property or method: 'mySessionPerson.firstName' 
End If 

Cualquier idea sobre lo que está pasando sería de gran ayuda.

Respuesta

1

¿No debería ser

If IsObject(Session("somePerson")) = true Then 
    set mySessionPerson = Session("somePerson") 
+0

No importa ya que los objetos en ASP Classic no se pueden serializar. –

+0

Lo siento, lo eché a perder en el ejemplo –

+0

@Jeffery: ASP y el objeto de sesión no conlleva ningún concepto de "serialización". – AnthonyWJones

3

No puedo explicar por qué su código no funciona se ve bien para mí.

El objeto se crea en un contexto de script que se destruye posteriormente después de completar la solicitud. Por lo tanto, mientras el nombre de tipo está disponible, la función del objeto está rota.

Puedo decirte que no es una buena idea almacenar objetos en la sesión, incluso aquellos que no se crearon en la secuencia de comandos.

La mayoría de los objetos utilizados en ASP existen en un único hilo. Una vez creado, solo el hilo que creó el objeto puede acceder al objeto. Para hacer frente a esto, una vez que ha almacenado un objeto en la sesión, ASP afilia la sesión con el hilo de trabajo específico que lo creó como objeto.

Cuando llega una solicitud posterior para esa sesión, ahora debe ser manejada por su hilo de trabajo específico. Si ese hilo está ocupado trabajando para alguna otra solicitud, la solicitud de sesiones está en cola, incluso si hay muchos otros hilos de trabajo disponibles.

El efecto general es dañar la escalabilidad de las aplicaciones donde la carga de trabajo puede distribuirse de manera desigual a través de los subprocesos de trabajo.

+0

He visto esto. El rendimiento se degrada con un número creciente de objetos en Sesión y Aplicación. – ssorrrell

2

Puedes hacer esto pero tienes que ser un poco astuto. Lo que entiendo es que cuando guardas un objeto horneado en casa, Session guarda todos los datos pero pierde toda la funcionalidad. Para recuperar la funcionalidad, debe "rehidratar" los datos de la sesión.

Aquí está un ejemplo en JScript para ASP:

<%@ Language="Javascript" %> 
<% 

function User(name, age, home_town) { 

    // Properties - All of these are saved in the Session 
    this.name = name || "Unknown"; 
    this.age = age || 0; 
    this.home_town = home_town || "Huddersfield"; 

    // The session we shall store this object in, setting it here 
    // means you can only store one User Object per session though 
    // but it proves the point 
    this.session_key = "MySessionKey"; 

    // Methods - None of these will be available if you pull it straight out of the session 

    // Hydrate the data by sucking it back into this instance of the object 
    this.Load = function() { 
     var sessionObj = Session(this.session_key); 
     this.name = sessionObj.name; 
     this.age = sessionObj.age; 
     this.home_town = sessionObj.home_town; 
    } 

    // Stash the object (well its data) back into session 
    this.Save = function() { 
     Session(this.session_key) = this; 
    }, 

    this.Render = function() { 
     %> 
     <ul> 
      <li>name: <%= this.name %></li> 
      <li>age: <%= this.age %></li> 
      <li>home_town: <%= this.home_town %></li> 
     </ul> 
     <% 
    } 
} 

var me = new User("Pete", "32", "Huddersfield"); 
me.Save(); 

me.Render(); 

// Throw it away, its data now only exists in Session 
me = null; 

// Prove it, we still have access to the data! 
Response.Write("<h1>" + Session("MySessionKey").name + "</h1>"); 

// But not its methods/functions 
// Session("MySessionKey").Render(); << Would throw an error! 

me = new User(); 
me.Load(); // Load the last saved state for this user 

me.Render(); 

%> 

Es bastante un poderoso método de gestión de ahorro de estado en la sesión y puede ser fácilmente swopped por DB llama/XML, etc., si es necesario.

Es interesante lo que Anthony plantea sobre los hilos, sabiendo su profundidad de conocimiento, estoy seguro de que es correcto y algo en lo que pensar, pero si es un sitio pequeño podrás salirte con la tuya, hemos usado esto en un sitio de tamaño mediano (10K visitantes por día) durante años sin problemas reales.

0

Crearía un objeto COM que se parece a su clase Person con VB6. Entonces almacena eso. El código es muy similar.

El método de Pete probablemente funcione.

-1

soy perezoso para probarlo por ti, pero

En lugar de:

set Session("somePerson") = aPerson 

Probar:

Set Session("somePerson") = Server.CreateObject(aPerson) 
0

datos de la sesión establecen del modo siguiente:

set Session.Contents("UserData") = UserData 

y luego obténgalo así:

Session.Contents("UserData.UserIsActive") 
Cuestiones relacionadas