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):
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!