Just trying to ascertain whether something is possible using an Abstract base class inherting from BusinessBase.
I have a structure like this
The main functionality exists in ObjectBase but the derived object override some of the main methods. Most of the objects though can be handled within the application as ObjectBase instances.
I would like to have a static method on ObjectBase such like
public static ObjectBase GetObject(int ID) {}
This should get the object of the correct type but returning this as type ObjectBase. So for example the ID specified could be a DerivedObjectA or DerivedObjectB. The trouble is the Type is not know untill the DB is queried. If know that if I wanted to call specific opertation then I would have to cast the object to the correct type.
Is this possible using a DataPortal_Fetch method in an Abstract base class?
One difficulty is that your ObjectBase is generic (inherit from BusinessBase<T>), and it'll need to be a conduit for your concrete classes to pass along their type so that the BusinessBase<T> methods are appropriately typed.
An option would be to inherit directly from Core.BusinessBase and stay away from Generics. (You'd have to implement the small amount of implementation done in BusinessBase<T> yourself).
Considering both options...
With the former approach (inheriting through BusinessBase<T>), you're kind of in trouble because you can't just call the static method on ObjectBase - see, ObjectBase isn't a class, it's a generic, so you can't just invoke your factory method on that class.
An option along these lines might be to have an ObjectBaseFactory, a separate class which has your static method which would have a command object to be invoked by your static GetObject(). It would return IObjectBase, which would be an interface declared on your ObjectBase class for the purposes of polymorphism. This command object would determine the appropriate class in a lightweight manner. The static GetObject on ObjectBaseFactory, using this command to determine the type, would then invoke the appropriate factory method on one of the concrete classes you implement to return an IObjectBase, which is then returned by ObjectBaseFactory's GetObject factory method.
What you are going to run into problems with, IMO, is the idea of the DerivedObjectA and DerivedObjectB (if you intend for these to both be concrete classes). Reason being that the type parameter being passed up to BusinessBase<T> will properly type one of your two classes. Maybe some of the experts in here can clear me up on that if I'm speaking incorrectly.
Along the lines of the other path - inheriting from Core.BusinessBase - you avoid the generic problem and I imagine you could have a static GetObject right on your ObjectBase class, which would return an ObjectBase (not necessarily an interface since ObjectBase is no longer generic). The approach would be the same, where one would have a lightweight command object to determine the type, and then you would invoke the factory method on the appropriate concrete class to return the concrete ObjectBase instance for the ObjectBase's GetObject factory method.
This latter approach, where you inherit from Core.BusinessBase, probably allows you to have "DerivedObjectA" and "DerivedObjectB", whereas I think it would be not feasible with the former approach of inheriting from BusinessBase<T>.
I hope this helps!
Thank for your input.
The idea of an object factory is something that I will probably implement. What I really wanted to avoid was having to hit the database twice, once the determine the type of object and one to get the data.
What I would have like to do is to obtain a datareader to determine the type of object in the derived object (or object factory for that matter) and then pass the datareader to the appropriate object. Trouble is this would be done server side by the CSLA and the object would already be created preventing me converting it to anything else. Will need to investigate the object factory a little more to see what I can do.
Just thought this would have been a problem that someone else might have had.
Copyright (c) Marimer LLC