Is this circular dependency a bad thing? Any potential problems?

Her开发者_高级运维e's the class I ended up with while building some data layer:

public class DataRequest
{
  public class DataResponse
  {
    public DataResponse(DataRequest req) { Request = req; }

    public DataRequest Request {get; set;}
    // ... here go some other fields ...
  }

  public Response { get; set; }

  public DataRequest()
  {
    Response = new DataResponse(this);
  }

  public void Execute()
  {
     ... Get some data and fill Response object ...
  }

}

I need request to be aware of response because it fills it with data; I need response to be aware of request because when I pass response to some other methods I want to have access to original request.

Do you see any potential problems with this architecture, like memory leaks, etc. or is it simply a bad design idea?

That doesn't look too evil, but you could also create a "DataContext" (for want of a better word) that exposes both the request and response, and only have each know about the context? i.e. to ask about the request the response would ask about:

this.Context.Request.SomeProperty;

It isn't a memory problem though; .NET doesn't do reference counting, so you don't need to worry about an island of circular references. If they are all unreachable from other objects, they'll get collected. The scenario in the question won't cause the world to end.

I think it's better to make a manager class holding both the request and the response properties , it will give you omore control than this

public class DataManager
{
   public DataRequest Request {get; set;}
   public DataResponse Response {get; set;}


  public void Excute () 
{
//do you logic here 
}

}