Re: EOModel needs an easy tweak
Re: EOModel needs an easy tweak
- Subject: Re: EOModel needs an easy tweak
- From: Farrukh Ijaz <email@hidden>
- Date: Sun, 7 Nov 2010 09:02:48 +0300
Hi Mark,
Thanks for the detailed explanation. Comments below:
On 2010-11-06, at 10:35 PM, Mark Wardle wrote:
> Hi Farrukh,
>
> I'm no expert on these matters but unless I have a very simple and
> straightforward plan of inheritance that would be immediately obvious
> to someone else joining the project, I've avoiding using EOF
> inheritance. I've dabbled with a number of options depending on the
> exact circumstances and most importantly, what has the *correct
> real-life semantic*.
>
> For instance, I've used enums to represent behaviours and have linked
> these to behaviour classes - the enterprise objects can simply call
> its registered behaviour object.method - I'm basing this on posts to
> the list from Ramsey.
Can you please explain a little bit more on this?
>
> In other situations, I've simply used java interfaces and implement
> these within separate entities perhaps factoring out common
> functionality into a helper class.
>
> For your case, I'm finding it difficult to imagine why two entities
> (IS-A) have such different relationship requirements.
The model has a legacy. In the beginning the entities appear to be different but semantically they are have some common behaviour when observed under specific domain . E.g. in a File System we have File and Folder (Directory) two separate entities. But at OS level, both have name, timestamp, permissions etc. The need before was to treat File and Folder as separate entities, but now the requirement demands to have some granularity among them. This is just an example to explain the situation.
> If you really
> need to do this and want to use EOF inheritance, then perhaps you can
> have two trees of inheritance. The first tree would have Entity X as
> root. These entities would defer handling of relationships to one of
> two entities that provide the appropriate relationship behaviour -
> to-one or to-many.
My domain knowledge is limited so I may need further explanation here too.
Farrukh
>
> Good luck,
>
> Mark
>
> On 6 November 2010 11:39, Farrukh Ijaz
> <email@hidden> wrote:
>> Hi EOF-ologists,
>>
>> I've a modelling issue and need to know what could be the suitable fix (or tweak) to fulfil the requirement.
>>
>> Below is the existing EO Model.
>>
>>
>> I've two entities (Entity A and Entity B) extending Abstract Entity X but these entities have their own tables (no single table inheritance). I need to design Entity D and Entity E where Entity D has a toMany relationship with Entity E and Entity E needs to have a toOne relationship with Entity A, Entity B, Entity C and Entity D.
>>
>> 1. One way can be for Entity E to have four different relationships such as toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
>> 2. The other way mentioned in the lower diagram where Entity A, Entity B, Entity C and Entity D extend Abstract Entity X and Entity E will have toOne relationship with Abstract Entity X. (This is _desirable_).
>>
>>
>> What would be the easiest way to model such relationship? I'm _not_ relationship expert so may be the way I assumed the model (second diagram) can be wrong or practically impossible?
>> Also note that I cannot make Entity C and Entity D to extend Abstract Entity X due to some design constraints therefore I think to introduce Abstract Entity Alpha.
>>
>> Thanks,
>>
>> Farrukh
>>
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
>
>
> --
> Dr. Mark Wardle
> Specialist registrar, Neurology
> Cardiff, UK
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden