2012-02-02 28 views
8

Alguien en una publicación here, comentó que no debe usar HttpContext.Current cuando usa MVC, más bien, debe usar ControllerBase.ControllerContext. En algunos aspectos, esto tiene sentido, pero en otros aspectos no tiene sentido.MVC, no "se supone" que usará HttpContext.Current nunca más?

Por ejemplo, ControllerContext es una variable de instancia, por lo que en todas partes quiero hacer referencia, por ejemplo, mis variables de sesión, ¿necesito tener una referencia al controlador? ¿Por qué "no se supone" que usemos HttpContext.Current en MVC, cuando todavía puedes? ¿Hay una "forma" de MVC "apropiada" para acceder a mi objeto de sesión sin tener que hacer referencia al controlador?

Sé con respecto a las pruebas, es mejor por razones expuestas en muchos otros lugares, pero estoy trabajando en un proyecto que gestiona las variables de sesión y las referencias HttpContext.Current y quiero saber si hay una mejor manera de obtener mis manos sobre el objeto Session sin pasar una referencia al controlador.

Respuesta

7

Esto se debe principalmente a que las pruebas unitarias serían muy difíciles si usa HttpContext.Current, ya que no es posible burlarse de este valor utilizando marcos de simulación normales.

HttpContext.Current también hace más código frágil ya que puede ser abusado y mal utilizado. Por ejemplo, puede usarlo en la capa empresarial, ya que es conveniente, pero se romperá si elige usar una capa de presentación alternativa que no sea ASP.NET.

En general, los métodos estáticos son actualmente desaconsejables ya que no pueden ser inyectados por dependencia.

1

Su publicación se debió a la simulación de pruebas, donde dependiendo de la simulación puede no haber un HttpContext, solo un contexto de controlador. De lo contrario, sí uso HttpContext.Current, simplemente no en mis pruebas unitarias.

Cuestiones relacionadas