É ok para definir Datacontext como uma propriedade no repositório?

Question

Existe algum problema em potencial na criação datacontext como propriedade como esta:

repositório

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

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

camada de serviço:

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

Answer 1

No DDD, você está perdendo a foto maior aqui referenciando as classes concret. Você não está interface entre o repositório e "camada de Serviços", de melhores práticas. Se você deve ter DataContext injetado no Repositório, eu recomendaria refatoração para:

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

A melhor solução seria a de deixar o punho Repository o DataContext por conta própria - mantendo a separação de concerto válido por mascarar os requisitos subjacentes:

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 você precisa manter o controle do DataContext (ou outra classe) mesmo (talvez você quer manter uma referência estática ao redor, ou alterar as configurações com base em um WebRequest, etc), você terá de usar um "Factory".

A fábrica seria algo parecido com isto:

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

Dessa forma, você tem controle total sobre a forma como a instância de DataContext é controlado fora e longe de sua "Serviços" da camada. Então, você usaria este DataContextFactory como o seguinte:

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

"Como acessar o IRepository?" você pode perguntar?

A sua camada de serviços faria algo como:

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

}

Ou, você poderia injetá-lo no construtor do seu serviço usando o seu sabor favorito de recipiente inversão de controle assim:

public class OrderService
{
  private IRepository _repo;

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

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

  }

Se você não estiver fimilar com os conceitos Locator Service, veja Castelo de Windsor como ele encapsula apenas sobre todas as suas necessidades.

Answer 2

Pelo que tenho lido, usando o DataContext " para mais do que uma conversa de negócios é geralmente a coisa errada a fazer ". Desça até a Por que isso é importante? seção para a citação. Devido ao cache e outros fatores, você deve considerar o seu DataContext obsoleto imediatamente. A partir disso, é seguro dizer que você não quer manter o DataContext como uma propriedade que é reutilizado por todos os seus métodos. Usando a sugestão de Eric Duncan, você vai querer passar em algum tipo de DataContext fábrica para obter um novo contexto para cada consulta.

Para uma discussão focada no DataContext, o APress Pro LINQ livro tem um capítulo sobre a DataContext, o muito última página de que também aconselha a "considerar os DataContext obsoleto imediatamente."