Persistencia de datos complejos entre las devoluciones de datos en ASP.NET MVC

Question

Estoy desarrollando una aplicación ASP.NET MVC 2 que se conecta a algunos servicios para realizar la recuperación de datos y la actualización. Los servicios requieren que proporcione la entidad original junto con la entidad actualizada al actualizar los datos. Esto es para poder cambiar el seguimiento y la concurrencia optimista. Los servicios no pueden ser cambiados.

Mi problema es que tengo que almacenar de alguna manera la entidad original entre las devoluciones. En WebForms, hubiera utilizado ViewState, pero por lo que he leído, eso está fuera de MVC. Los valores originales no tienen que ser a prueba de manipulaciones ya que los servicios los tratan como no confiables. Las entidades serían (max) 1k y es una aplicación de intranet.

Las opciones que he subido son:

1. Sesión - Descartado - Almacenar la entidad en el período de sesiones, pero no me gusta esta idea ya que no hay planes para compartir sesión entre
2. URL - descartado - datos es demasiado grande
3. HiddenField - Almacenar la entidad serializado en un campo oculto, tal vez con el cifrado/codificación
4. HiddenVersion - Las entidades tienen un campo de versión (SQL) en ellas, que podría poner en un campo oculto. Luego, al guardar, obtengo la entidad "original" de los servicios y comparo las versiones, haciendo mi propia concurrencia optimista.
5. Galletas - como 3 o 4, pero utilizando una cookie en lugar de un campo oculto

me estoy inclinando hacia la opción 4, aunque 3 serían más simples. ¿Son estas opciones válidas o voy por el camino equivocado? ¿Hay una mejor manera de hacer esto?

Answer 1

Si lo almacena en una sesión, debe asegurarse de que si implementa una granja de servidores web, la sesión se carga correctamente.

Tenemos (exactamente) la misma pregunta aquí en este momento y lo que hemos decidido hacer es implementar el patrón de repositorio y vincularlo a una cookie.

Luego, si esto se convierte en un problema, simplemente podemos insertar un administrador de sesión, administrador de db o lo que sea, y nuestro código ni siquiera necesita saberlo debido al patrón de repositorio.

Hemos jugado con la idea de campos ocultos, pero se parecía demasiado a ViewState y todos lo odiamos en WebForms, por lo que la idea se eliminó. Pero no solo porque odiamos ver el estado. Hubo problemas cuando presionó Ctrl F5. El contenido se borrará y ¿qué haces?

Por lo tanto, en este punto es un patrón de repositorio con una cookie que puede cambiar, pero la implementación se presta a cambios.

EDITAR

también decidimos contra los campos ocultos, ya que sería demasiado fácil de realizar cambios en ellos y por lo que tiene que hacer algunas cosas token del servidor para asegurarse de que wans't manipulado.

Los campos ocultos siguen agregando complejidad a lo que esencialmente debería haber sido un problema muy simple.

Al menos esa fue nuestra opinión al respecto.

Answer 2

No estoy muy seguro de por qué Session es una mala idea, si la dosis del cliente no necesita esa copia de seguridad, mantener todo en la memoria del servidor suena mejor; ya que el resto de los candidatos están todos enviando de un servidor a otro (temporal) en el navegador de los clientes, y luego lo recuperan cada vez que el cliente realiza alguna acción. La situación es que, siempre que el cliente realice un ping back, el servidor descomprimirá los datos codificados (ya sea en el campo oculto, cookie, url, etc.) y posiblemente los coloque nuevamente en el servidor. También desperdicia ancho de banda IMO.

OK, si el cliente necesita (para inspeccionar) la copia de seguridad, consideraría el campo oculto (conjunto) o simplemente serializaría los datos en XML y los colocaría en algún lugar del HTML.

EDIT

Sigo votando por la Sesión. Si va a tomar el cuidado de la granja de servidores, considere implementar un proveedor de sesión de servidor cruz:

http://msdn.microsoft.com/en-us/library/ms178587%28VS.80%29.aspx

y simplemente almacenar el estado de la base de datos.