J'ai l'impression de courir en cercles. Je n'arrive pas à me décider sur ce que la droite modèle de référentiel est à l'aide de LINQ to SQL. Si vous êtes familier avec Rob Conery du MVC Vitrine , vous verrez que sa mise en œuvre enveloppe le LINQ modèles générés avec une autre classe et traite le LINQ généré simplement comme un objet de transfert de données (DTO). Il ressemble à quelque chose comme ceci:
//Custom wrapper class.
namespace Data
{
public class Customer
{
public int Id {get;set;}
public string Name {get;set;}
public IList<Address> Addresses {get;set;}
}
}
//Linq-Generated Class - severly abbreviated
namespace SqlRepository
{
public class Customer
{
public int Id {get;set;}
public string Name {get;set;}
public EntitySet<Address> {get;set;}
}
}
//Customer Repository
namespace SqlRepository
{
public class UserRepository : IUserRepository
{
private _db = new DB(); //This is the Linq-To-Sql datacontext
public IQueryable GetCusomters()
{
return
from c in _db.Customers
select new Customer // This is the wrapper class not the gen'd one
{
Id = c.Id,
Name = c.Name,
Addresses = new LazyList(c.Addresses)
};
}
Quel est l'avantage de cette façon de faire (à l'aide d'une classe wrapper), par opposition à la façon dont Mike Hadlow suggère, à l'Aide de la IRepository modèle avec LINQ to SQL dans sa version de IRepository<T>, où il retourne juste la DTO des objets du référentiel?
Où la logique métier être appliquées et contrôlées? Est-ce dans un autre calque, tous ensemble, appelé par le référentiel sur enregistrer/mettre à jour, ou est-il intégré à la classe wrapper?
