Si hereda de la base NegotitatedContentResult<T>
, como se mencionó, y no necesita transformar su content
(por ejemplo, solo desea devolver una cadena), entonces no necesita anular el ExecuteAsync
método.
Todo lo que necesita hacer es proporcionar una definición de tipo adecuada y un constructor que le indique a la base qué código de estado HTTP debe devolver. Todo lo demás simplemente funciona.
Aquí hay ejemplos para ambos NotFound
y InternalServerError
:
public class NotFoundNegotiatedContentResult : NegotiatedContentResult<string>
{
public NotFoundNegotiatedContentResult(string content, ApiController controller)
: base(HttpStatusCode.NotFound, content, controller) { }
}
public class InternalServerErrorNegotiatedContentResult : NegotiatedContentResult<string>
{
public InternalServerErrorNegotiatedContentResult(string content, ApiController controller)
: base(HttpStatusCode.InternalServerError, content, controller) { }
}
Y luego puede crear los métodos de extensión correspondientes para ApiController
(o hacerlo en una clase base si tiene una):
public static NotFoundNegotiatedContentResult NotFound(this ApiController controller, string message)
{
return new NotFoundNegotiatedContentResult(message, controller);
}
public static InternalServerErrorNegotiatedContentResult InternalServerError(this ApiController controller, string message)
{
return new InternalServerErrorNegotiatedContentResult(message, controller);
}
Y luego funcionan como los métodos integrados. Puede llamar al existente NotFound()
o puede llamar a su nuevo personalizado NotFound(myErrorMessage)
.
Y, por supuesto, puede deshacerse de los tipos de cadenas "codificados" en las definiciones de tipos personalizados y dejarlos genéricos si lo desea, pero luego puede que tenga que preocuparse por las ExecuteAsync
cosas, dependiendo de lo que <T>
realmente sea.
Puede revisar el código fuente para NegotiatedContentResult<T>
ver todo lo que hace. No hay mucho que hacer.