¿Está bien establecer Datacontext como una propiedad en el repositorio?

Question

¿Hay algún problema potencial al establecer datacontext como propiedad como esta:

repositorio

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

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

capa de servicio:

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

Answer 1

En DDD, te estás perdiendo la imagen más grande haciendo referencia a las clases concretas. No está interactuando entre el Repositorio y la capa de Servicios " por las mejores prácticas. Si debe tener DataContext inyectado en el repositorio, recomendaría refactorización 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
  }
}

La mejor solución sería dejar que el Repository maneje el DataContext por su cuenta, manteniendo la separación del concierto válida al enmascarar los requisitos subyacentes:

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 debe mantener el control del DataContext (u otra clase) usted mismo (tal vez desee mantener una referencia estática o cambiar la configuración en función de una solicitud web, etc.), deberá usar un " Factory " .

La fábrica se vería así:

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

De esa manera, usted tiene control total sobre cómo se controla la instancia de DataContext fuera y fuera de sus " Servicios " capa. Entonces, usaría este DataContextFactory de la siguiente manera:

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

" ¿Cómo acceder al IRepository? " puedes preguntar?

Su capa de servicios haría 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();

}

O, lo inyectarías en el constructor de tu servicio utilizando tu sabor favorito del contenedor Inversión de control así:

public class OrderService
{
  private IRepository _repo;

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

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

  }

Si no está familiarizado con los conceptos del localizador de servicios, eche un vistazo a Castle Windsor, ya que abarca casi todas sus necesidades.

Answer 2

De lo que he leído, usando el DataContext " para más de una conversación de negocios es generalmente lo que no se debe hacer . " Desplácese hasta la sección ¿Por qué es esto importante? para la cotización. Debido al almacenamiento en caché y otros factores, debe considerar que su DataContext está obsoleto de inmediato. A partir de eso, es seguro decir que no desea mantener el DataContext como una propiedad que todos sus métodos reutilizan. Usando la sugerencia de Eric Duncan, querrá pasar algún tipo de DataContext factory para obtener un nuevo contexto para cada consulta.

Para una discusión centrada en el DataContext, el libro APress Pro LINQ tiene un capítulo completo en el DataContext, el muy la última página de la que también se recomienda que " considere el estado de DataContext obsoleto de inmediato. "