That depends on how you define the model:

In your case `Relation` is a single relation which can be traversed both ways. 
This does indeed describe the real life better.

The model I suggests looks more like what you see on many social networks, how 
they implement the "friend" relationship: User(1) can specify that User(2) is 
its friend, but that doesn't necessarily mean that User(2) wants User(1) as its 
friend. Those are 2 separate things.

It all depends on what Swapna wants.

PS: I've implemented these kind of relations before, using both models. My 
experience is that the "2 relations" approach is much easier to maintain (even 
though is less strict/clean in a DDD sense). In case you want to mimmic the "1 
relation" model you do _need_ to implement something to keep those 2 relations 
in sync (either have both, or have none, but _never_ just one). But besides 
that everything else will be simpler to do. I believe this is one of those 
things you just have to weigh the pros/cons and make the appropriate decision 
for you particular use-case ;)

PPS: I agree that RelationType would be a value object!

-- 
Jasper N. Brouwer
(@jaspernbrouwer)


On 1 Apr 2014, at 11:23, Herman Peeren <[email protected]> wrote:

> On Tuesday, 1 April 2014 10:48:22 UTC+2, Jàπ (Jasper N. Brouwer) wrote:
>> The reason I suggest using 2 `Relation` entities is because using this 
>> throughout your app will be much easier. When you need to know all the 
>> relatives of User(1), you can simple query all `Relation::$relatedToUser` 
>> users where `Relation::$user` is User(1). 
>> When using only one `Relation` entity, you would have to query for all 
>> `Relation::$relatedToUser` users where `Relation::$user` is User(1) OR all 
>> `Relation::$user` users where `Relation::$relatedToUser` is User(1). 
> 
> Many ways leading to Rome... Thank you for your advice, Jasper. Very 
> interesting. But I personally would use 1 Relation entity instead of 2 here, 
> as it is modeling one and the same relation, only named differently from the 
> other perspective. Your choice to model that as two different "things" is a 
> valid one, of course, but I prefer to stay as much as possible to the domain 
> I'm modeling. Probably this is just a matter of a bit different 
> implementation of the same model, but you cannot see child-of and parent-of 
> separately of each other: it is just the same "thing", with two different 
> names. 

-- 
You received this message because you are subscribed to the Google Groups 
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to