Create an object by specifying type name

To your second question: See MSDN: Implementing Finalize and Dispose to Clean Up Unmanaged Resources[^].

I have several comments on your code:

• unusual naming scheme for C# (inconsitent lower/upper case wording, etc.). Have a look at Design Guidelines for Developing Class Libraries[^].
• you use derivation where composition is probably clearer: why childBOLoader to derive from Dictionary? Do you want expose all Dictionary methods to the client of the childBOLoader class? No one would expect the childBOLoader to be a Dictionary. Better use composition instead.
• Your class does not implement IDisposable interface (it's missing in the class header). Why do you think you need to dispose anything - you are here in a garbage collected environment.
• You are using casts without cause - I regard casts as code smell, i.e. either avoid or comment why cannot avoid. Use the generic enumerator instead. But since your "Is-A" Dictionary instead of a "Has-A" Dictionary implementation, it looks odd anyways how you enumerate over the content of the dictionary. If it was cmposition, you would do a foreach loop (you can do that here too:
  C#

  foreach (var item in Values)
  {
     var obj = item as IDisposable; // only call Dispose on IDisposable objects
     if (obj != null) obj.Dispose(); 
  }

  or simpler if you BaseBusinessLayer class implements IDisposable:
  C#

  foreach (var item in Values) item.Dispose();

Cheers
Andi

Regarding creation of the various business objects (without seeing more of your architecture) I'd consider a single builder/getter function that takes the construction expression as a lambda and creates and inserts the object into the _childBOs Dictionary

public BaseBusinessLayer getBO(Func<BaseBusinessLayer> factory)
{
    BaseBusinessLayer newBO = factory();
    string boName = newBO.GetType().Name;
    _childBOs.Add(boName);
    return newBO;
}

And then you would invoke it like:

BaseBusinessLayer someBO = getBO(() => new DialRecalls());

[Edit]
If you don't like the idea of the lambda expressions, then you can restructure the inheritence hierarchy using generics so allow for a static method, implemented once in the BaseBusinessLayer class to factory the instances.

using System;

namespace ConsoleApplication27
{
  class Program
  {
    static void Main(string[] args)
    {
      var dl = DialLog.Factory();
      Console.WriteLine("dl is type: " + dl.GetType().Name);
      var dr = DialRecalls.Factory();
      Console.WriteLine("dr is type: " + dr.GetType().Name);
    }
    abstract class BaseBusinessLayer<T> where T:BaseBusinessLayer<T>, new()
    {
      protected BaseBusinessLayer()
      {
      }
      static public T Factory()
      {
        return new T();
      }
    }
    class DialLog : BaseBusinessLayer<DialLog>
    {
    }
    class DialRecalls : BaseBusinessLayer<DialRecalls>
    {
    }
  }
}

And the use with the getBO method above would be:

BaseBusinessLayer someBO = getBO(DialRecalls.Factory);

Basic example of creating an object by its type name:

IFilter filter = Activator.CreateInstance(Type.GetType("PriceSectionFilter")) as IFilter;

In this case all of the different filter types would need to derive from an interface or base class.

You could also do a google search for "c# factory pattern". There are plenty of ways to do what you are trying to do.

Hope that helps a little.

All 29 loadBO methods have been reduced to this:

public BaseBusinessLayer getBO(Func<BaseBusinessLayer> factory)
{
    BaseBusinessLayer newBO = factory();
    string boName = newBO.GetType().Name;
   _childBOs.AddBO(boName, newBO);
    return _childBOs[boName];
}

Invoked like this:

DialRecalls someBO = (DialRecalls)getBO(() => new DialRecalls());

Is this kind of what you meant ... because it works great!

Everyone ... thanks so much! I should have started posting questions here more often! You see, I develop alone ... so to me, all of my ideas are perfect <not>!

Andi:

As a matter of fact, each BusinessObject implements a Dispose method ... as such (at least I think it does):

/// <summary>
/// Clean up any resources being used.
/// </summary>
/// <param name="disposing">true if managed resources should be disposed; otherwise, false.</param>
protected override void Dispose(bool disposing)
{
    if (disposing && (components != null))
    {
        components.Dispose();
    }
    base.Dispose(disposing);
}

Your other suggestion works nicely as follows:

private void dispose(bool isDisposing)
{
    if (isDisposing)
    {
        foreach (var item in Values) item.Dispose();
    }
}

Why do I think I have to dispose of anything?

The answer to that is easy ... I'm not comfortable (ignorant of) garbage collection in general. Just can't get my head around the default behavior to know whether or not it should be implemented in one of my classes. Does this class even require and implementation of IDisposable?

Why did I use a generic Dictionary<string,>?

It seemed like a good fit and no ... the only method I really needed was Add to add a BO to the dictionary.

Unusual naming scheme for C#

Can you point out an example? The reference you gave is quite voluminous ... an example will let me focus on a problem area first ... then I can extrapolate for others.

Casts without cause ...

I assume you are meaning this line of code?

return (DialRecalls)_childBOs["oDialRecalls"];

When I remove the cast I get an error "Cannot implicitly convert type 'SouthendBOL.BaseBusinessLayer' to 'SouthendBOL.PriceSectionFilter'. An explicit conversion exists (are you missing a cast?)

But since your "Is-A" Dictionary instead of a "Has-A" Dictionary implementation

Hate to admit it in public but this is a new concept to me ... care to expand on that a bit ... or provide a link for a more in depth explanation?

As for the factory method ... it appears that particular pattern likes to create an instance of all participating objects. This is not what I need. The current implementation is so simple (it takes relatively no time to add a new method) and it is so clear as to what is going on when implemented, that adding a OO pattern would add to complexity with very little benefit.

Another reason I like this implementation is that all BOs are available ... but they are only loaded when needed. Also, only critical business objects, the ones that participate in application events (like PrintInvoice ... which may involve CustomerBO, SalesTaxTableBO, InvoiceHeaderBO, InvoiceLineItemsBO ... etc) even have a method created for them.

Missing a class header ...

Well, here I go again ... can you give an example of a class header? Sorry ... newbie.

CTB

I can't thank you all enough ... this is an excellent forum!