Circular-dependency best practice

Question

I'm currently writing a web scraper which retrieves information from the internet. Simplified it looks like this.

Data access project

• Objects to retrieve raw data
• Objects to parse the the raw data into objects (!!)
• The entities that the parser returns.

Now, I'm creating the actual parser, and I'm going to use it like this:

using Application.DataAccess;
using Application.DataAccess.Entities;

namespace Application{
 public class TestScraper{
  public static ScrapeIt()
  {
   var source = DataAcces.Retriever.Retrieve("http://example.com");
   DataAccess.Entities.Entity entity = DataAccess.Parser.Parse(source);

   //Do stuf with source here.
  }
 }
}

As you can see, the Parser returns a Entity. However this is in the DataAccess namespace, yet, it makes no sense... it´s a circle, and I don´t really know how to fix this. Well I could come up with a few things, like creating another layer between those layers.

But I just want to know, how would YOU solve this. And what is a good (or the best practice) for this.

Answer 1

You can fix a circular reference by factoring out the things that both classes refer to into a new class, and then the old classes both refer to the new class.

So in your case you could move the entities out of DataAccess and into perhaps a new Entities namespace, used by both DataAccess and Application.

By doing this you start with

A <--> D

and end up with

A --> E
D --> E

Answer 2

Data Access Layer should not be in the same namespace as your domain objects. Entities should stand alone in an assembly/namespace that does not reference any other namespace, which will allow other logic based classes such as DataAccess and Parsers to reference the Entity on their own in a more clean manner.