Pasar valores y guardar los valores temporalmente, ... sesión de uso, campo oculto, cadena de consulta o de otro tipo?

Question

Esto puede ser una pregunta básica ... Sin embargo me acaban recogiendo una solución sin dar mucho sin embargo a ella ...

Considere una página con una rejilla de formas: /FormList.aspx

donde elegir para editar una forma redirige al usuario a una página como: /FormEdit.aspx?Id=2

Por lo general estoy bien con el paso de los valores en la cadena de consulta, porque puedo comprobar en el código subyacente de FormEdit que la identificación es válida. Que es el mejor manera de pasar el valor , sin embargo: sesión o cadena de consulta ? U otro?

Mientras el usuario está editando la forma ... normalmente guardar el ID temporalmente en la sesión (para evitar la reciba de nuevo la url). Durante la edición forma del usuario, lo que es el mejor manera de almacenar el valor ? En el sesión o en un campo oculto ? ¿U otro? (Cuando quiero almacenar un DataTable temporal, creo que sólo puedo utilizar la sesión, pero cuando es un valor entero ...)

Gracias de antemano por sus sugerencias:)

Answer 1

Yo sugeriría a no utilizar Session algo que puede fácilmente y rápidamente se almacena y se comprueba en una cadena de consulta o campo de formulario oculto; la información que parece estar hablando aquí es perfecto para la cadena de consulta.

Tenga en cuenta que Session podría introducir errores cuando alguien intenta editar múltiples formas a la vez en diferentes pestañas. Cuando se ahorra uno, el valor Session sería tomada desde el último cargaron para salvar ... probablemente no lo que se desea, y probablemente sería difícil de resolver esto.

Lo que debe hacer es persistir el formid en los campos de cadena de consulta / forma, y ??simplemente doble comprobar que la cordura cuando presenten el proceso de almacenamiento; Asegúrese de que es un identificador que existe y que se les permite editar, por ejemplo.

Answer 2

Normalmente cadena de consulta es una buena opción si tiene datos muy pequeños para trasfer entre sus páginas.

2- Sesión sería un gran cuando se quiere almacenar datos específicos de usuario.

en ti caso, mejor sería la cadena de consulta que usted está enviando datos muy pequeños (ID) a la siguiente página.

Answer 3

Algunas cosas a tener en cuenta:

1. Si la manipulación del valor es un riesgo para la seguridad que necesita para cualquiera de guardarlo en el lado del servidor, o asegurar el lado del cliente valor (que no es fácil de conseguir correcta). O aún mejor:. Recalulate ellos
2. Ahorro en la sesión puede crear fácilmente problemas si el usuario tiene la página web abierta en varias pestañas al mismo tiempo. También puede romper el botón de retroceso.
   Por ejemplo, si a salvo el ID del tema, el usuario está modificando en la sesión, y las ediciones de los usuarios dos entradas al mismo tiempo, el contenido de la que comenzó la edición de la primera podría ser escrito en la entrada empezó a editar más tarde.

Answer 4

Mi sugerencia es mantener el valor de una variable de sesión, pero cuando se ejecuta el Page_Load de FormEdit.aspx por primera vez, guardar el valor en el ViewState de la página, y borrar la sesión var.

Algo por el estilo (en Page_Load de FormEdit.aspx):

if (!IsPostBack)
{
    ViewState["MyVar"] = Session["MyVar"];
    Session.Remove("MyVar");
}

Answer 5

El problema con las cadenas ASP.NET y la consulta es que persisten en las devoluciones de datos. Es decir, la acción de formulario, de los quebrantos de página a la url que incluye la cadena de consulta que se utilizó para cargarlo.

Si el ID en cuestión sólo se utiliza para elegir una forma particular (y no está relacionado con los datos de usuario) esto no es un gran problema, de hecho, es probable que lo que quiere.

Por otro lado, si se identifica un registro, puede que no quiera esto. Suponiendo un mejor código correctamente, esto no debería suponer un riesgo para la seguridad, pero puede dar al usuario la impresión de que hay un solo exponiendo el ID interno de un registro en la cadena de consulta. También sólo se ve lamentable.

Hay formas de evitar esto, y creo que en 3.5 se puede cambiar mediante programación la acción del formulario. (Solía ??ser que tenía que usar javascript para hacer que - a pesar de la acción del formulario se expuso que no podía ser cambiado).

La mejor manera de lidiar con esto es las cadenas de consulta evitar para cualquier identificadores de registro de datos. Use Puestos que los registros de datos de carga en su lugar, por ejemplo, en lugar de utilizar un asp: control de hipervínculo, utilice un asp: control de LinkButton.

Por supuesto, ya PUESTOS cargar la misma página que se obtienen de, esto requiere que los formularios estén en la misma página que su lista. Así, en lugar de tener dos páginas separadas, FormList.aspx y FormEdit.aspx, sólo hay que poner el código en la misma página para que pueda publicar directamente de vuelta. Es de suponer que cada una de sus formas es en un control de usuario de todos modos. Por lo que su página principal simplemente tiene la tarea de elegir qué Usercontrol para mostrar, todo lo demás se delega a los controles de usuario, y todo el parámetro de paso puede ser realizado a través de mensajes dentro de su página principal. Esta es una mejor arquitectura y mantiene todo agradable y limpio.