I have a Business layer (BL) and a Data layer (DL). I have an object o with a child objects collection of Type C. I would like to provide a semantics like the following o.Children.Add("info"). In the BL I would like to have a static CLASS that all of business layer classes uses to get a reference to the current datalayer instance. Is there any issue with that or must I use the factory pattern to limit creation to A class in the BL that knows the DL instance.
Let me Clarify. In the past when defining DL I create an interface IDL that the DL implements. The only objects I allow to be created from my BL are the factories which in their constructors take A reference to the IDL
IDL idlRef = new DataLayer(); IBlFactory iFac = new BLFactory(IDL); IBLa = IBlFactory.Geta(...);
As I have tried to work statics and singletons out of my system my factory creates all the objects and always passes the reference the the IDL to the new objects. Some on my team have complained about my copious use of interfaces and factories and would like to utilize concrete classes from the BL directly.
So the issue is if you have a object which can be created IE a new object are you better severed by utilizing the factory. IE
IBLA oBLA = iFac.GetBLA();
or forcing the client to always passing the reference to the DL to new object. IE BLA oBLA = new BLA(idlRef);
or would testability really be harmed by having one static property in the BL.
Static IDL CurrentDL;
Allowing albeit with some breaking of encapsulation more succinct style Assuming that each BL object will know what the currentDL is.