title: Properly Refactoring to avoid a Circular Dependency
body: <p>I am having a problem with a circular dependency.  Similar question have been asked and I have read a lot of answers.  Most deal with a work-around but I would like to refactor so what I have it correct and I would like some input on where I have gone wrong.  I can change what I am doing but not the entire project architecture. </p>
  
  <p>I am using VB.Net in Visual Studio 2012.</p>
  
  <p>I have two class libraries:</p>
  
  <ol>
  <li><strong>DataLayer</strong> for accessing the database.</li>
  <li><strong>DataObject</strong> which contains classes that represents my business objects.</li>
  </ol>
  
  <p>My Presentation Layer calls methods in the DataLayer which returns objects from the DataObject class library.<br/>
  <em>(I have simplified somewhat – I actually have a controller layer but it needs references to the two class libraries above.  This is an existing architecture that is from before my time.)</em></p>
  
  <p>In the DataObject class library I have an abstract class that represents a file.  It has properties such as filename, userID, etc.  It also has a method, GetFile(), that I code in the derived classes because there are different ways of getting the file.  A DataLayer method returns a collection of these file objects, but I don't want to get the actual file until it's needed.
  <br/><br/><br/>
  So far, I have a derived class that calls a webService (using properties from the baseClass) and a derived class that accesses the fileSystem.  Both return a byte array representing the file.  The calling class does not need to know how the file is retrieved. 
  <br/><br/>Now I have a new requirement to build the file on the fly using data from the database.  I can get all the data I need using the properties in the base class.  <br/>
  <br/><strong>My issue is that my GetFile() method will need to access my DataLayer class library to pull data from the database which causes a circular dependency.</strong>   The DataLayer class library has a reference to DataObject since that is what it returns.  But now I need to call the DataLayer from a class in DataObjects.
  <br/><br/></p>
  
  <ul>
  <li>I could call the DataLayer from presentation and pass the result to
  my DataObject’s GetFile() method, but then my presentation layer
  needs to do something special for this derived class.  My goal is
  that the derived class handles GetFile without presentation knowing
  about the implementation.</li>
  <li>I could create a new class library for this DataLayer code but I
  don't like a special case.</li>
  <li>I could access the DB directly in the DataObject class but that
  circumvents the layered architecture.</li>
  </ul>
  
  <p>I can’t change our architecture, but I can change my approach.  </p>
  
  <p>Any opinions?</p>