2011-03-28 15 views
7

Tengo una acción de controlador que hace algo de trabajo en la base de datos y luego sale cuando está terminada. Esta acción se está llamando a través de la función ajax de jQuery con el tipo de datos establecido en 'json'.ASP.NET MVC - Manera correcta de manejar acciones ajax sin objeto devuelto

Si configuro el tipo de devolución de la acción a anular, todo funcionará bien, excepto que Firefox mostrará un error en la consola que dice: "no se encontró ningún elemento".

Tiene sentido que Firefox arroje este error si esperaba que XML volviera. Sin embargo, incluso cuando cambio la propiedad dataType de la llamada ajax a "texto", todavía recibo el error. Para deshacerse del error con el tipo de retorno void, tendría que configurar ContentType de respuesta a "text/html". O podría establecer el tipo de devolución a JsonResult y devolver un nuevo objeto JsonResult [vacío].

Estoy seguro de que hay varias maneras en que puedo hacer que este error desaparezca, pero quería saber la forma correcta de manejar las acciones sin que se invoquen valores de retorno a través de ajax.

Si es importante, también estoy usando el patrón de acción de controlador asíncrono.

public void DoSomethingAsync(SomeJsonObjectForModelBinding model) 
{ 
    // do some database things 
} 

public void DoSomethingCompleted() 
{ 
    // nothing to do... 
    // what should my return type be? 
    // do I need to set the content type here? 
} 

Respuesta

11

Sé que esto no responde exactamente a su pregunta, pero yo diría que siempre debe tener un valor de retorno al volver de un AJAX o llamada de servicio web. Aunque solo sea para decirle que la operación fue exitosa, o devolverle el error (mensaje).

a menudo definir una clase como esta:

public class JsonResultData 
{ 
    private bool _success = true; 
    public bool Success 
    { 
     get { return _success; } 
     set { _success = value; } 
    } 

    public object Value { get; set; } 
    public List<string> Errors { get; set; } 


    public JsonResultData() 
    { 
     this.Errors = new List<string>(); 
    } 
} 

y luego usarlo para devolver datos o cualquier otra meta datos de llamadas en la envoltura JsonResultData así:

return new JsonResult { 
      Data = new JsonResultData { Value = returnValue, Success = true } 
      }; 
+1

+1 para siempre devolver el éxito o el error, realmente necesario en la medida en que funciona el modo js. –

+2

No veo lo que esto te compra en absoluto. Un estado de http siempre será devuelto por el servidor de todos modos. Usted está abogando por jpassing json datos serializados para el cliente a pesar de que * usted sabe que nunca será leído *. ¿Cuál es el punto de? – fearofawhackplanet

+1

Bueno, hay comentarios a nivel de sistema, y ​​luego hay comentarios a nivel de aplicación. Puede tener una ejecución exitosa de AJAX, pero no tendría idea si algo salió mal en el servidor dentro de su aplicación. – Kon

0

no puedo comentar por mi reputación, pero aún así quería contribuir a despejar la confusión en la respuesta de Kon.

En una aplicación capté todas las excepciones dentro de un método de acción, establecí un HttpStatusCode y agregué un mensaje de error a la respuesta. Extraje el mensaje en la función de error Ajax y se lo mostré al usuario.

Todo salió bien hasta que la aplicación se puso en el servidor de almacenamiento intermedio, que tenía algún tipo de configuración que no permitía un mensaje de devolución dentro de una respuesta errónea. En su lugar, se transmitió algún Html estándar que dio como resultado un error JS al procesar la respuesta.

Al final tuve que volver a escribir todo mi manejo de excepciones devolviendo mis errores de aplicación como una exitosa llamada Ajax (que realmente es) y luego difiero dentro de la función de éxito Ajax, tal como debería ser.

Debe no comentarios de nivel de sistema de mezcla y nivel de aplicación. Es posible que no pueda controlar los comentarios al nivel del sistema de la manera que su aplicación lo necesita.

Cuestiones relacionadas