I've recently discovered how to put TargetPerEntityHierarchy to good use and am making the most of it.

One thing that I've run into though and am wondering how best to handle it are the casting issues in relation to the various entities. I know this is part OO 101, but I'm interested in the LL specifics of it!

Say I've got this heirarchy:

Base
    |-Person
        |-Manager

So each derives from (and is castable to) a BaseEntity obj. But how best can I do the following:

• 1. Determine what sub-type a particular obj is (Base, Person, or Manager)?
• 2. How can I downcast to a specific type once I've determined it? I was hoping Person or Manager might have a "New(e as IEntity)" so that I could just create a new obj of the specific type and pass in the base, but no go (and I'm thinking if it's not already there, well there's a good reason for it)
• 3. Assume that Manager has relation that the sub-types do not. How can I best dynamically determine that by inspecting the obj?

(also, I'm in .NET 2.0 - so no 3.5 wizardry allowed)

As always, LL rocks - the more I learn, the better it is!

Appreciation in advance!

jsaylor wrote:

1. Determine what sub-type a particular obj is (Base, Person, or Manager)?

someEntity.GetType() 

or

if (someEntity is ManagerEntity)

jsaylor wrote:

1. How can I downcast to a specific type once I've determined it? I was hoping Person or Manager might have a "New(e as IEntity)" so that I could just create a new obj of the specific type and pass in the base, but no go (and I'm thinking if it's not already there, well there's a good reason for it)

The best natural thing is casting:

ManagerEntity m =  (ManagerEntity) someEntity;

jsaylor wrote:

1. Assume that Manager has relation that the sub-types do not. How can I best dynamically determine that by inspecting the obj?

Is that possible (a subtype that doesn't have the parent relations?). Please elaborate more.

daelmo wrote:

jsaylor wrote:

1. Determine what sub-type a particular obj is (Base, Person, or Manager)?

someEntity.GetType() 

or

if (someEntity is ManagerEntity)

Ok.

daelmo wrote:

jsaylor wrote:

1. How can I downcast to a specific type once I've determined it? I was hoping Person or Manager might have a "New(e as IEntity)" so that I could just create a new obj of the specific type and pass in the base, but no go (and I'm thinking if it's not already there, well there's a good reason for it)

The best natural thing is casting:

ManagerEntity m =  (ManagerEntity) someEntity;

Hmmm, I'm thinking C# differs from VB here (and I think we're into covariance territory, though I'm not an expert in this area). Let's take Person instead of Manager, since they're in the middle of the hierarchy. In both VB/C#, this works because we casting up the hierarchy (specific->general):

C#: (BaseEntity) b = (BaseEntity) somePersonEntity;
VB: Dim b as BaseEntity = CType( somePersonEntity, BaseEntity)

But, casting down the heirarchy (general->specific) only works in C#:

C#: (PersonEntity) p = (PersonEntity) someBaseEntity;

Try and do this in VB and you'll get an error (with Option Strict On, and presuming the original obj was created as BaseEntity):

VB: Dim p as PersonEntity = CType( someBaseEntity, PersonEntity)

Unfortunately, I'm still not really well versed on generics but I have casually read some stuff that leads me to believe that with them you can achieve primarily the same thing. I was hoping somebody might have some insight how to best do this on the VB side with LL.

daelmo wrote:

jsaylor wrote:

1. Assume that Manager has relation that the sub-types do not. How can I best dynamically determine that by inspecting the obj?

Is that possible (a subtype that doesn't have the parent relations?). Please elaborate more.

Let's say the base table has a nullable FK to another table called ManagementStuff. You can then select the Manager entity in the hierarchy and create a relation to ManagementStuff that supertypes (Base and Person) don't have. How is it best to "inspect" (hopefully not using reflection) the Entity in question to determine what relations it might have?

Ultimately, what I'm trying to avoid is littering case (switch in C#) statements in the code that handle Base, Person, and Manager differently. What I'd rather do is query the objects to determine what they're capabilities are and then drive decisions on it: mostly UI - for example, display the ManagementStuff editor only if we have a Manager selected.

The answer to all your question is that most probably you won't need any of these. !!

That's because in this case LLBLGenPro uses Polymorphic Fetches. Please search for this term in the user manual.

When fetching entities of type base, you will get a collection of entities, each instatiated from its specific type, so you won't need to down cast anything.

Walaa wrote:

The answer to all your question is that most probably you won't need any of these. !!

That's because in this case LLBLGenPro uses Polymorphic Fetches. Please search for this term in the user manual.

When fetching entities of type base, you will get a collection of entities, each instatiated from its specific type, so you won't need to down cast anything.

I only briefly looked at the docs, but on first blush it looks like exactly what I was hoping for!

This is what I mean about LL - the more I learn about it, the happier I am.

With too many other products, when I hit a brick-wall during an arc of effort, it's the end of the road (sorry, the product just doesn't do that). I'm thrilled to say that, most of the time (indeed, so far I think 100% of the time!) LL is always a step or two ahead.

Thanks again, Cheers - Jeff

Thanks for the feedback Jeff