Question

Is there any potential problem in setting datacontext as property like this:

repository

public Repository() {      public DataContext dc {get;set;}      public GetOrders(int id)        { ...from dc.Orders...} } 

service layer:

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

Answer 1

In DDD, you’re missing the bigger picture here by referencing the concret classes. You are not interfacing between the Repository and ‘Services layer’ by best practices. If you must have DataContext injected into the Repository, I would recommend refactoring to:

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

The better solution would be to let the Repository handle the DataContext on its own – keeping the seperation of concert valid by masking the underlying requirements:

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

If you must keep control of the DataContext (or another class) yourself (perhaps you want to keep a static reference around, or change settings based on an WebRequest, etc), you you will need to use a ‘Factory’.

The factory would look something like this:

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

That way, you have full control over how the instance of DataContext is controlled outside and away from your ‘Services’ layer. So, you would use this DataContextFactory like the following:

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

‘How to access the IRepository?’ you may ask?

Your services layer would do something like:

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

Or, you would inject it into the constructor of your service using your favorite flavor of Inversion of Control container like so:

public class OrderService {   private IRepository _repo;    public OrderService(IRepository repo)   {     _repo = repo;   }    public void GetNewOrdersForServices()   {     IList myList = _repo.GetNewOrders();    } 

If you are not fimilar with the service locator concepts, check out Castle Windsor as it Encapsulates just about all your needs.