Où va mon code CRUD LINQ? ASP.NET MVC

Question

Je suis actuellement en utilisant le framework ASP.NET MVC sur un projet (à peu près ma première fois)

J'utilise Linq2SQL comme mon modèle de données ..

Où dois-je avoir ce genre de code:

var entries = from e in db.sometable select e; 

J'ai actuellement ce code un peu dans le contrôleur et transmettre les données d'entrer dans la vue ..

est-ce correct? Sinon comment puis-je comprendre mon code de linq2sql pour inclure ce genre de code?

Merci

Daniel

Answer 1

Il est courant d'utiliser le modèle référentiel pour MVC. En général, vous définissez une interface, par exemple, IProducts, puis vous implémentez cette interface en appelant le code linq2sql. Votre contrôleur acceptera cette interface en tant que paramètre pour le constructeur, de sorte que cela dépend de cette interface, et non d'une classe concrète. L'utilisation d'un injecteur de dépendances, tel que Ninject, vous permettra de fournir une implémentation d'interface concrète au constructeur. Cela permet le test unitaire sur votre application web, et ajoute également de la flexibilité.

Il y a un très bon livre, Pro ASP.NET MVC 2 Framework, qui explique tout cela. Je suis en train de le lire, et j'adore ça.

Answer 2

Il est bien d'avoir des requêtes Linq dans les méthodes du contrôleur. Si nous parlons de la séparation des préoccupations, l'idée est que votre couche de données (dans ce cas, le référentiel (?) Code qui vous fournit db.sometable) découple votre code logique (les méthodes de contrôleur dans ce cas) de le magasin de données.

Vous interrogez les données couche plutôt que la base de données, de sorte que vous pouvez modifier la banque de données sous-jacente et votre code de contrôleur fonctionnera toujours. Certains diront qu'il est préférable de déplacer le plus de code logique possible hors des contrôleurs et dans le code de votre modèle (voir the first answer here), mais cela dépend de la distance que vous voulez parcourir.

Answer 3

Voici un exemple de la façon de mettre en œuvre la repository pattern

En plus de cela, je mettre en œuvre une couche supplémentaire pour gérer vos applications logique métier et garder vos contrôleurs léger

Answer 4

Pour ajouter ce dit @Poco, voici un exemple:

En Foo.Common.Repositories (à l'intérieur du projet Foo.Common):

public interface IRepository<T> 
{ 
    IEnumerable<T> GetAll(); 
    void Update(T entity); 
    void Add(T entity); 
    void Delete(T entity); 
    void Save(); 
} 

public interface IUserRepository : IRepository<User> 
{ 
    void GetByCredentials(string username, string password); 
} 

L'intérieur Foo.Data.Repositories (à l'intérieur Foo.Data projet):

public class UserRepository 
{ 
    // ... other methods/properties snipped. 

    public IEnumerable<User> GetAll() 
    { 
     // Where this.Users would be L2Sql or Code-First... or some other ORM. 
     return from u in this.Users orderby u.Name select u; 
    } 
} 

ensuite dans votre réelle Foo.Web:

public class UserController : Controller 
{ 
    private readonly IUserRepository userRepository; 

    public UserController(IUserRepository userRepository) 
    { 
     this.userRepository = userRepository; 
    } 

    [AcceptVerbs(HttpVerbs.Get)] 
    public ViewResult List() 
    { 
     var users = this.userRepository.GetAll(); 
     return this.View(users); 
    } 
} 

Et dans votre Global.asax vous auriez Ninject ou d'un autre conteneur IoC pour résoudre IUserRepository:

public static void RegisterServices(IKernel kernel) 
{ 
    kernel.Bind<IUserRepository>().To<UserRepository>(); 
} 

protected void Application_Start() 
{ 
    var kernel = new StandardKernel(); 

    AreaRegistration.RegisterAllAreas(); 

    MvcApplication.RegisterGlobalFilters(GlobalFilters.Filters); 
    MvcApplication.RegisterRoutes(RouteTable.Routes); 
    MvcApplication.RegisterServices(kernel); 

    // I'm using MVC3 here: 
    DependencyResolver.SetResolver(new NinjectResolver(kernel)); 
}