views:

67

answers:

2

So, the object model is rather complex and hierarchical. Grandfather accepts is created by a GrandfatherFactory that accepts a GrandfatherRepository in it's constructor.

All is well.

Now when Grandfather needs to load it's Children how does it do it?

How does it know about the ChildFactory and ChildRepository? It shouldn't correct?

But then how does it load them? I wouldn't think you pass a ChildFactory into the Grandfather constructor, as if you have Grandchildren (which this app does) you'd need to pass in a GrandchildFactory as well!

Do you instantiate some kind of EverythingFactory that has all of the different types of factories inside of it and pass that into each constructor and they make use of the one they care about?

Or is there some simple solution I'm just not seeing?

Currently all the objects call a webservice to load their data, and I'm trying to pull that out and make a Repository interface that can be mocked for testing purposes.

EDIT: Ignore the factories, I don't need them, I think I was just over-complicating things.

Currently the objects load their data, and child data by way of webservice calls scattered about in the objects.

Most of the objects constructors are marked private, and they have static methods like "LoadByID(int)" to retrieve them from the db.

Then when the property which contains it's child methods is referenced, if it's private "child list" variable is empty, it calls Child.GetAllChildrenFor(this); which is a static method of Child, and "this" is the Parent class. It calls the webservice, creates all the Childs, and returns a list of them, each of which has a reference to it's parent.

I know this isn't quite right...but I don't know where I've gone wrong, or how to correct it to be able to REMOVE the webservice calls and put in a Repository interface that can be real or mock... and where in the code I set which to use!

EDIT2: The code is something along these lines currently

public interface IEntity
{
 int ID { get; set; }
}

public class Parent : IEntity
{
 public int ID { get; set; }

 private Children children;
 public Children Children 
 { 
  get 
  {
   if (this.children == default(Children)) 
   {
    this.children = Children.GetChildrenFor(this);
   }
   return this.children;
  }
 }
}

public class Children : List<Child>
{
 private Children() { }

 public static Children GetChildrenFor(Parent parent)
 {
  Children children = new Children();

  DataSet childrenDataSet = new DataSet();
  using (webservice) 
  {
   childrenDataSet = webservice.Retrieve(parent.ID)
  }

  if (childrenDataSet.HasRows())
  {
   foreach (DataRow dr in childrenDataSet.Tables[0].Rows)
   {
    Child rr = Child.LoadByDataRow(dr);
    rr.Parent = parent;
    children.Add(rr);
   }
  }

  return children;
 }
}

public class Child : IEntity 
{
 public Parent Parent { get; set; }
 public int ID { get; set; }

 internal static Child LoadByDataRow(DataRow dr)
 {
  Child child = new Child();

  child.ID = dr.Field<int>("ID");
  child.GrandChild = GrandChildren.GetGrandChildrenFor(this);

  return child;
 }
}
A: 

Create a hierarchy of Factories. ChildFactory inherits the FatherFactory, which inherits the GrandfatherFactory. Maybe the factories can be templated, or you could use the Abstract Factory design pattern.

Igor Oks
+1  A: 

One way to factor this code out of static methods and make it mock-able is to create an IRepository interface that defines a contract for classes that will supply your entities.

public interface IRepository {
    Parent GetParent(int parentId);
    List<Child> GetChildrenByParent(int parentId);
    // ...
}

Next, change your entities to require an IRepository in their constructors:

public class Parent: IEntity {
    private IRepository repository;
    public Parent(IRepository repository) {
        this.repository = repository;
    }
    // ...
}

A concrete IRepository implementation will contain code to call web services and map their results to each of your entities; it will have to pass itself in when it constructs entities, like this:

public class ConcreteRepository: IRepository {
    public Parent GetParent(int parentId) {
        Parent parent = new Parent(this);
        // Call web service, perform mapping, etc.
    }
}

Entities constructed like this can use the repository as needed - for example, in the Parent.Children get accessor. Your applications will use a real repository, while unit tests can supply a mock or stub.

Jeff Sternal
So my mistake is trying to create a repository for each entity rather than one repository that contains methods for all of them?
Chad
It's not a mistake, just a design decision - in fact you might still implement separate entity repositories under the covers. I'm only proposing a single repository (basically an abstract factory, insofar as repositories are specialized factories) to simplify the API.
Jeff Sternal
Working on it now, and I am seeing how with ONE repository (which later could be a facade for several) makes this work MUCH simpler. I'm starting it out by just creating a class with a pile of static methods and dragging any calls to the webservice into them. And from there I should be able to refactor it to implement an interface and create a mock object... small steps. Hopefully by next week I'll have code that I can write tests for...
Chad