ASP.net MVC Controller-Uso del constructor

RCravens tiene algunas ideas excelentes. Me gustaría mostrarle cómo puede implementar sus sugerencias.

Sería bueno comenzar definiendo una interfaz para la clase data access a implementar:

public interface IPostRepository 
{
    IEnumerable<Post> GetMostRecentPosts(int blogId);
}

Luego implementa una clase de datos. Los contextos de Entity Framework son baratos de construir, y se puede obtener un comportamiento inconsistente cuando no se dispone de ellos, así que me parece que por lo general es mejor extraer los datos que desea en la memoria, y luego disponer del contexto.

public class PostRepository : IPostRepository
{
    public IEnumerable<Post> GetMostRecentPosts(int blogId)
    {
        // A using statement makes sure the context is disposed quickly.
        using(var context = new BlogContext())
        {
            return context.Posts
                .Where(p => p.UserId == userId)
                .OrderByDescending(p => p.TimeStamp)
                .Take(10)
                // ToList ensures the values are in memory before disposing the context
                .ToList(); 
        }
    }
}

Ahora su el controlador puede aceptar uno de estos repositorios como argumento constructor:

public class BlogController : Controller
{
    private IPostRepository _postRepository;
    public BlogController(IPostRepository postRepository)
    {
        _postRepository = postRepository;
    }

    public ActionResult Index(int blogId)
    {
        var posts = _postRepository.GetMostRecentPosts(blogId);
        var model = new PostsModel { Posts = posts };
        if(!posts.Any()) {model.Message = "This blog doesn't have any posts yet";}
        return View("Posts", model);
    }

}

MVC le permite usar su propia Fábrica de Controladores en lugar del predeterminado, por lo que puede especificar que su marco de IoC como Ninject decida cómo se crean los Controladores. Puede configurar su marco de inyección para saber que cuando solicite un IPostRepository debe crear un objeto PostRepository.

Una gran ventaja de este enfoque es que hace que sus controladores sean comprobables por unidad. Por ejemplo, si desea asegurarse de que su modelo recibe un mensaje cuando no hay publicaciones, puede usar un marco de burla como Moq para configurar un escenario donde su repositorio no devuelve publicaciones:

var repositoryMock = new Mock<IPostRepository>();
repositoryMock.Setup(r => r.GetMostRecentPosts(1))
    .Returns(Enumerable.Empty<Post>());
var controller = new BlogController(repositoryMock.Object);
var result = (ViewResult)controller.Index(1);
Assert.IsFalse(string.IsNullOrEmpty(result.Model.Message));

Esto hace que sea fácil probar el comportamiento específico que espera de las acciones de su controlador, sin necesidad de configurar su base de datos ni nada especial como eso. Las pruebas unitarias como esta son fáciles de escribir, deterministas (su estado de aprobado / no aprobado se basa en el código, no en el contenido de la base de datos), y rápido (a menudo se puede ejecutar un millar de estos en un segundo).