Factory and collection design

jnapier · **Joined:** Sat Sep 10, 2005 3:46 pm **Posts:** 178

I have an entity called Process. Process has a collection of Procedures. Process is also the factory for a Procedure. Process looks like this:

Code:

public class Process{
   ...
   IList Procedures{
      get{...}
   }

   public Procedure CreateProcedure(string name){
      Procedure operation = new Procedure(this);
      operation.Name = name;
      return operation;
   }
   ...
}

Now my questions, should I add the Procedure to the Process's Procedures collection in the create operation or should I explicity add the Procedure to the Process after Creation?

In the Parent/Child example in the documentation, an AddChild method is used to simplify adding the child to the Parent's children collection and set the parent of the child. This makes sense but exposing the collection as a property off of the parent also exposes the collection's add method. So it could be confusing to a developer as to which method to call, AddChild() or parent.Children.Add(). How have others worked with this probelm? Is it something I should even be worried about?

It would be cool if the collection exposed events that could be tapped into. then you could trap for the add event and set the child's parent in the event.

If a child is added into a parent's collection is it better to update the parent in the session and let persistence by reachability take over or is it better design to explicity save the child directly to the session and persist it that way?

Thanks for any help.
Jesse

KPixel · **Posted:** Fri Oct 07, 2005 8:00 am

What I do is:
- Ask NHibernate to access the private field collection
- Create Add/Remove/Contains/... for this collection
=> Type-safe and I can do any work I have to in this methods.

jnapier · **Joined:** Sat Sep 10, 2005 3:46 pm **Posts:** 178

KPixel, what would an example of your contains operation look like? Is the contains operation the only place your provide access to iterate over the collection, well the only place off of the aggragate root?

Any comments on the factory piece of the question? Or were you suggestion that after creation, the caller would have to call the Add operation?

KPixel · **Posted:** Tue Oct 11, 2005 9:02 am

Here is what I had in one of my old projects:

Code:

      /// <summary> Gets the number of MyEntity actually contained in the ParentEntity. </summary>
      public int MyEntityCount
      {
         get
         {
            return this._myEntity.Count;
         }
      }
      /// <summary> Adds a MyEntity to the collection. </summary>
      public int Add(MyEntity item)
      {
         // Pre-Logic here
         if(item==null)
            throw new System.ArgumentNullException("item");
         if(this.Contains(item))
            throw new System.ArgumentException("This item is already in the Collection. Remove and Insert it.", "item");
         int pos = this._myEntity.Add(item);
         item.ParentEntity = this;
         // Post-Logic here
         return pos;
      }
      /// <summary> Removes all MyEntity from the collection. </summary>
      public void ClearMyEntity()
      {
         // Pre-Logic here
         this._myEntity.Clear();
         // Post-Logic here
      }
      /// <summary> Determines whether the collection contains a specific MyEntity. </summary>
      public bool Contains(MyEntity item)
      {
         return this._myEntity.Contains(item);
      }
      /// <summary> Determines the index of a specific MyEntity in the collection. </summary>
      public int IndexOf(MyEntity item)
      {
         return this._myEntity.IndexOf(item);
      }
      /// <summary> Inserts a MyEntity to the collection at the specified position. </summary>
      public void Insert(int index, MyEntity item)
      {
         // Pre-Logic here
         if(item==null)
            throw new System.ArgumentNullException("item");
         if(this.Contains(item))
            throw new System.ArgumentException("This item is already in the Collection. Remove it before.", "item");
         this._myEntity.Insert(index, item);
         item.ParentEntity = this;
         // Post-Logic here
      }
      /// <summary> Removes the specific MyEntity from the collection. </summary>
      public void Remove(MyEntity item)
      {
         // Pre-Logic here
         this._myEntity.Remove(item);
         item.ParentEntity = null;
         // Post-Logic here
      }
      /// <summary> Removes the MyEntity at the specified index. </summary>
      public void RemoveMyEntityAt(int index)
      {
         // Pre-Logic here
         ((MyEntity)_myEntity[index]).ParentEntity = null;
         this._myEntity.RemoveAt(index);
         // Post-Logic here
      }
      /// <summary> Gets the MyEntity at the specified index. </summary>
      public MyEntity GetMyEntityAt(int index)
      {
         return this._myEntity[index] as MyEntity;
      }

About the factory, it heavily depends on the architecture of your application... I don't see any "best practise" here.

jnapier · **Joined:** Sat Sep 10, 2005 3:46 pm **Posts:** 178

Wow. Thats a lot of work.

So it appears that the collection is never directly exposed and there is no way to iterate over it. If using an IList you could resolve this by Returning a ReadOnly IList with the help of ArrayList.Readonly(IList). This would elimiate the need for a couple of methods you exposed such as IndexOf and Contains.

KPixel · **Posted:** Wed Oct 12, 2005 1:33 pm

jnapier wrote:

Wow. Thats a lot of work.

Actually, I used MyGeneration to generate that... :wink:

jnapier · **Joined:** Sat Sep 10, 2005 3:46 pm **Posts:** 178

Of course. I guess i meant to say, thats alot of code. Thanks for the replies.