ASP.net MVC Contrôleur - Constructeur d'utilisation

RCravens a quelques excellentes idées. J'aimerais vous montrer comment vous pouvez mettre en œuvre ses suggestions.

Il serait bon de commencer par définir une interface pour l'accès aux données de la classe à mettre en œuvre:

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

Mettre en œuvre une classe de données. Entity Framework contextes ne sont pas chers à construire, et vous pouvez obtenir un comportement incohérent lorsque vous ne jetez pas d'eux, donc je trouve qu'il est généralement préférable d'extraire les données que vous voulez dans la mémoire, puis jetez-le contexte.

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(); 
        }
    }
}

Maintenant votre contrôleur peut accepter qu'un seul de ces dépôts comme un argument du constructeur:

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 vous permet d'utiliser votre propre Contrôleur d'Usine en lieu et place de celle par défaut, vous pouvez spécifier que votre Cio cadre comme Ninject décide de la manière dont les Contrôleurs sont créés. Vous pouvez configurer votre infrastructure d'injection de savoir que lorsque vous demandez une IPostRepository il doit créer une PostRepository objet.

Un grand avantage de cette approche est qu'il rend vos contrôleurs de l'unité-testable. Par exemple, si vous voulez vous assurer que votre modèle reçoit un Message quand il n'y a pas de postes, vous pouvez utiliser un moqueur cadre comme Moq pour définir un scénario où votre référentiel renvoie pas de postes:

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));

Cela rend plus facile pour tester le comportement que vous attendez de vos actions de contrôleur, sans avoir besoin de configurer votre base de données ou quelque chose de spécial comme ça. L'unité des tests de ce genre sont faciles à écrire, déterministe (leur statut de réussite/échec est basé sur le code, pas le contenu de base de données), et rapide (vous pouvez souvent exécuter un millier de ces dans une seconde).