asp.net-mvc - validacion - variable de sesion asp net mvc

Cuándo usar TempData vs Session en ASP.Net MVC

Question

Estoy tratando de entender el framework MVC así que tengan paciencia conmigo.

En este momento, lo único que estoy usando en el almacén de sesión es almacenar el usuario registrado actualmente. Mi sitio web es simple. Para este ejemplo, considere tres objetos de dominio, Persona, Reunión y Archivo. Los usuarios pueden iniciar sesión y ver el perfil "solo para miembros" de una reunión y agregarle archivos, o ver el "perfil" público de una reunión si no están conectados.

Entonces, desde el perfil privado de la reunión, con un usuario conectado, tengo un enlace "agregar archivos". Este enlace se dirige a FileContoller.Add (int meetingId). A partir de esta acción, obtengo la reunión a la que el usuario desea agregar archivos usando la identificación de reunión, pero después de que se haya publicado el formulario, aún necesito saber a qué reunión está agregando archivos el usuario. Ahí radica mi pregunta, ¿debo aprobar la reunión "actualmente interactuando con" a través de TempData, o agregarla a la tienda de la sesión?

Esta es la forma en que actualmente tengo la configuración Agregar acción, pero no está funcionando:

    public ActionResult Add(int meetingId)
    {
        try
        {
            var meeting = _meetingsRepository.GetById(meetingId);
            ViewData.Model = meeting;
            TempData[TempDataKeys.CurrentMeeting] = meeting; /* add to tempdata here */
        }
        catch (Exception)
        {
            TempData[TempDataKeys.ErrorMessage] = "Unable to add files to this meeting.";
            return RedirectToRoute("MeetingsIndex");
        }

        return View();
    }

    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Add(FormCollection form)
    {
        var member = Session[SessionStateKeys.Member] as Member;
        var meeting = TempData[TempDataKeys.CurrentMeeting] as Meeting; /* meeting ends up null here */

        if (member == null)
        {
            TempData[TempDataKeys.ErrorMessage] = "You must be logged in to add files to an meeting.";
            return RedirectToRoute("LoginPage");
        }

        if (meeting == null) 
        {
            TempData[TempDataKeys.ErrorMessage] = "An error occurred. No meeting selected.";
            return RedirectToRoute("MeetingsIndex");
        }

            // add files to meeting

        TempData[TempDataKeys.Notification] = "Successfully added.";
        return RedirectToRoute("AddFiles", new {meetingId = meeting.MeetingId});
}

Editar:

En función de la mayoría de las respuestas, ¿puede alguien dar algún ejemplo sobre qué tipo de datos (distintos de los mensajes) deberían almacenarse en TempData vs Session?

Answer 1

"No funciona" no es muy descriptivo, pero permítame ofrecerle algunas sugerencias.

Bajo el capó, TempData usa Session para almacenar valores. Entonces, no hay mucha diferencia en términos de mecanismos de almacenamiento o algo así. Sin embargo, TempData solo dura hasta que se reciba la siguiente solicitud.

Si el usuario hace una solicitud de Ajax entre las publicaciones del formulario, TempData se va. Cualquier solicitud que borre TempData. Por lo tanto, solo es confiable cuando realizas una redirección manual.

¿Por qué no puedes simplemente presentar la ID de reunión en un campo oculto en tu formulario de vista? Ya lo está agregando al modelo. Alternativamente, agréguelo a su ruta como un parámetro.

Answer 2

El proveedor predeterminado de TempData usa la sesión, por lo que realmente no hay mucha diferencia, excepto que su TempData se borra al final de la siguiente solicitud. Debe usar TempData cuando los datos solo necesiten persistir entre dos solicitudes, preferiblemente la segunda es una redirección para evitar problemas con otras solicitudes del usuario, desde AJAX, por ejemplo, borrando los datos accidentalmente. Si los datos deben persistir durante más tiempo, debe volver a llenar el archivo TempData o usar la sesión directamente.

Answer 3

El valor de la propiedad TempData se almacena en estado de sesión. El valor de TempData persiste hasta que se lee o hasta que la sesión expira. Si desea pasar datos de una vista de controlador a otra vista de controlador, entonces debe usar TempData.

Use la sesión cuando los datos necesiten la aplicación completa

Answer 4

Prefiero mantener ese tipo de datos en la página en sí. Render meetingID como una entrada oculta, por lo que se envía de vuelta al controlador. El controlador que maneja la publicación puede luego devolver esa Id. De reunión a la vista que se muestre, de modo que la ID de reunión básicamente se transfiera todo el tiempo que la necesite.

Es como la diferencia entre almacenar un valor en una variable global antes de llamar a un método que operará en él, o pasar el valor directamente al método.

Answer 5

Puedes usarlo según tu requerimiento. Una aclaración puede ser,

TempData Vs Session

TempData

1. TempData nos permite persistir los datos para la duración de la única solicitud posterior.
2. ASP.net MVC caducará automáticamente el valor de tempdata una vez que la solicitud consecutiva haya devuelto el resultado (es decir, estará activo solo hasta que la vista de destino esté completamente cargada).
3. Es válido solo para solicitudes actuales y posteriores

4. TempData tiene el método Keep para retener el valor de TempData.

   Ejemplo:

   TempData.Keep (), TempData.Keep ("EmpName")

5. TempData almacenó internamente el valor en la variable Session.

6. Se usa para almacenar solo mensajes de una sola vez como mensajes de validación, mensajes de error, etc.

Sesión:

1. La sesión puede almacenar datos mucho más tiempo, hasta que la sesión del usuario no caduque.
2. La sesión caducará una vez transcurrido el tiempo de espera de la sesión.
3. Es válido para todas las solicitudes.
4. N / A
5. Session varible se almacena en el objeto SessionStateItemCollection (que se expone a través de la propiedad HttpContext.Session de la página).
6. Se utiliza para almacenar datos de larga duración como ID de usuario, ID de rol, etc. que se requieren durante la sesión del usuario.

TempData y sesión, ambos requieren conversión de tipo para obtener datos y verificar valores nulos para evitar la excepción de tiempo de ejecución.

Answer 6

Sugeriría la solución de MvcContrib: http://jonkruger.com/blog/2009/04/06/aspnet-mvc-pass-parameters-when-redirecting-from-one-action-to-another/

Si no quieres MvcContrib completo, la solución es solo 1 método + 1 clase que puedes tomar fácilmente de fuentes MvcContrib.

Answer 7

TempData es sesión, por lo que no son del todo diferentes. Sin embargo, la distinción es fácil de entender, porque TempData es solo para redireccionamientos y redireccionamientos . Entonces, cuando configura un mensaje en TempData y luego lo redirecciona, está utilizando TempData correctamente.

Sin embargo, usar Session para cualquier tipo de seguridad es extremadamente peligroso. La sesión y la membresía están completamente separadas en ASP.NET. Puede "robar" sesiones de otros usuarios , y sí, las personas atacan sitios web de esta manera. Por lo tanto, si desea detener selectivamente una información de publicación según si un usuario inició sesión, ver IsAuthenticated y si desea mostrar selectivamente la información según el tipo de usuario que haya iniciado sesión, use un proveedor de roles . Dado que los GET se pueden almacenar en caché, la única forma de permitir el acceso selectivo a una acción en un GET es con AuthorizeAttribute.

Actualización En respuesta a su pregunta editada: Ya tiene un buen ejemplo del uso de TempData en su pregunta, es decir, devolver un mensaje de error simple después de una POST fallida. En términos de lo que se debe almacenar en Session (más allá de "no mucho"), solo pienso en Session como un caché específico del usuario. Al igual que la caché no específica del usuario, no debe colocar allí información confidencial. Pero es un buen lugar para colocar cosas que es relativamente caro de buscar. Por ejemplo, nuestro Site.Master tiene el nombre completo del usuario que se muestra en él. Eso se almacena en una base de datos, y no queremos hacer una consulta de base de datos para cada página que servimos. (Una instalación de nuestra aplicación se usa en una sola compañía, por lo que el nombre completo de un usuario no se considera "sensible a la seguridad"). Por lo tanto, si considera que la Sesión es un caché que varía según la cookie que tiene el usuario, no ganó estar muy equivocado