CODEWITHSUNDEEP
c#architecture
Andrey
Andrey

Reputation: 21285

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

Here'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?

Upvotes: 4

Views: 195

Answers (2)

Amgad Fahmi
Amgad Fahmi

Reputation: 4349

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 
}

}

Upvotes: 1

Marc Gravell
Marc Gravell

Reputation: 1062610

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.

Upvotes: 6

Related Questions