Va bene impostare Datacontext come proprietà nel repository?

Question

C'è qualche potenziale problema nell'impostazione di datacontext come proprietà come questa:

repository

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

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

livello di servizio:

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

Answer 1

In DDD, ti stai perdendo il quadro più ampio qui facendo riferimento alle classi concrete. Non stai eseguendo l'interfaccia tra il repository e il "Livello servizi" dalle migliori pratiche. Se è necessario che DataContext sia iniettato nel repository, consiglierei il refactoring su:

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 soluzione migliore sarebbe lasciare che il repository gestisca da solo il DataContext - mantenendo valida la separazione dei concerti mascherando i requisiti sottostanti:

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
  }
} 

Se devi mantenere tu stesso il controllo di DataContext (o di un'altra classe) (forse vuoi mantenere un riferimento statico o modificare le impostazioni in base a un WebRequest, ecc.), dovrai utilizzare un " Factory " .

La fabbrica sarebbe simile a questa:

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
    // 
  }
}

In questo modo, hai il pieno controllo su come l'istanza di DataContext è controllata all'esterno e lontano dai tuoi "servizi" strato. Quindi, useresti questo DataContextFactory come il seguente:

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
    }
  }
} 

" Come accedere a IRepository? " potresti chiedere?

Il tuo livello di servizi farebbe qualcosa del genere:

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

}

Oppure, lo inseriresti nel costruttore del tuo servizio usando il tuo sapore preferito del contenitore Inversion of Control in questo modo:

public class OrderService
{
  private IRepository _repo;

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

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

  }

Se non sei simile ai concetti di localizzatore di servizi, dai un'occhiata a Castle Windsor in quanto incapsula praticamente tutte le tue esigenze.

Answer 2

Da quello che ho letto, utilizzando il DataContext " perché più di una conversazione d'affari è di solito la cosa sbagliata da fare . " Scorri verso il basso fino alla sezione Perché è importante? per il preventivo. A causa della memorizzazione nella cache e di altri fattori, è necessario considerare immediatamente DataContext obsoleto. Da ciò, è sicuro di dire che non si desidera mantenere DataContext come una proprietà che viene riutilizzata da tutti i metodi. Usando il suggerimento di Eric Duncan, vorrai passare una specie di factory DataContext per ottenere un nuovo contesto per ogni query.

Per una discussione incentrata sul DataContext, il libro APress Pro LINQ ha un intero capitolo su DataContext, il molto ultima pagina di cui ti consiglia anche di " considerare immediatamente DataContext obsoleto. "