Est-il possible de définir Datacontext en tant que propriété du référentiel?

Question

Existe-t-il un problème potentiel lors de la définition de la propriété datacontext comme suit:

référentiel

public Repository()
{ 
    public DataContext dc {get;set;}

    public GetOrders(int id)
       { ...from dc.Orders...}
}

couche de service:

public GetNewOrders()
   {
       ....
       Repository rep=new Repository();
       using {DataContext dc=new DataContext())
        { 
           rep.dc=dc;
           rep.GetOrders(id);
        }
    }

Answer 1

Dans DDD, il vous manque la vue d'ensemble en référençant les classes de concrets. Vous n’interférez pas entre le référentiel et les "couches de services". par les meilleures pratiques. Si DataContext doit être injecté dans le référentiel, je vous recommande de refactoriser à:

public interface IRepository
{
  IList<Orders> GetNewOrders();
}
public Repository : IRepository
{
  private IDataContext _dataContext;
  public Repository(IDataContext dataContext)
  {
    _dataContext = dataContext;
  }
  public IList<Orders> GetNewOrders()
  {
    // perform your actions on _dataContext here
  }
}

La meilleure solution serait de laisser le référentiel gérer seul le DataContext - conserver la séparation de concert valide en masquant les exigences sous-jacentes:

public interface IRepository
{
  IList<Orders> GetNewOrders();
}
public Repository : IRepository
{
  private IDataContext _dataContext;
  public Repository(String connectionString)
  {
    _dataContext = new DataContext(connectionString);
  }
  public IList<Orders> GetNewOrders()
  {
    // perform your actions on _dataContext here
  }
} 

Si vous devez garder vous-même le contrôle du DataContext (ou d'une autre classe) (vous souhaitez peut-être conserver une référence statique ou modifier les paramètres en fonction d'un WebRequest, etc.), vous devrez utiliser une "Factory". .

L'usine ressemblerait à ceci:

public static class DataContextFactory
{
  public static IDataContext GetInstance()
  {
    // return either a static instance, 
    // or threaded instance, a GlobalContext instance
    // or whatever your preference is here
    // 
  }
}

Ainsi, vous avez le contrôle total sur le contrôle de l'instance de DataContext en dehors et à l'écart de votre " Services " couche. Ainsi, vous utiliseriez cette DataContextFactory comme suit:

public interface IRepository
{
  IList<Orders> GetNewOrders();
}
public Repository : IRepository
{
  public IList<Orders> GetNewOrders()
  {
    using (var dataContext = DataContextFactory.GetInstance())
    {
      // dataContext is now your IDataContext to work with
    }
  }
} 

"Comment accéder à IRepository?" vous pouvez demander?

Votre couche de services ferait quelque chose comme:

public void GetNewOrdersForServices()
{
  // Not recommended!
  //      IRepository repo = new Repository()
  //
  // The following is recommended instead; because, it removes the
  // the Concret reference from your Services layer completely!
  //
  IRepository repo = ServiceLocator.InstanceOf<IRepository>();
  IList myList = repo.GetNewOrders();

}

Sinon, vous l'injecteriez dans le constructeur de votre service en utilisant votre version préférée du conteneur Inversion of Control, comme suit:

public class OrderService
{
  private IRepository _repo;

  public OrderService(IRepository repo)
  {
    _repo = repo;
  }

  public void GetNewOrdersForServices()
  {
    IList myList = _repo.GetNewOrders();

  }

Si vous n'êtes pas familier avec les concepts de localisateur de services, consultez Castle Windsor car il englobe à peu près tous vos besoins.

Answer 2

D'après ce que j'ai lu, j'utilise DataContext " pour plus d'une conversation professionnelle est généralement la mauvaise chose à faire . " Faites défiler jusqu'à la section Pourquoi est-ce important? pour la citation. En raison de la mise en cache et d'autres facteurs, vous devez immédiatement considérer votre DataContext périmé. À partir de là, il est prudent de dire que vous ne voulez pas conserver le DataContext en tant que propriété réutilisée par toutes vos méthodes. En suivant la suggestion d’Eric Duncan, vous voudrez transmettre une sorte d’usine DataContext pour obtenir un nouveau contexte pour chaque requête.

Pour une discussion axée sur le DataContext, le livre APress Pro LINQ contient un chapitre entier sur le DataContext, le très La dernière page vous conseille également de "considérer immédiatement le périmètre de DataContext".