Best Practice for transactional join tables in Java EE 5

[Arved Sandstrom]

When using "Entity Classes from Database" in Netbeans 6.x, and there is a
pre-existing join table, no @ManyToMany join table gets set up; instead the
join table becomes an entity that has two @JoinColumns, each a @ManyToOne
to one of the joined entities. Each of the joined entities has a @OneToMany
Collection of the join table entities.

To make it easier, let's say that one joined entity is Person, the other is
Address, and the join table ends up as PersonAddress. As it stands, in
order to get all the addresses for a given person, you need to get all the
PersonAddress'es (through getPersonAddressCollection in Person), and then
iterate through that and invoke getAddress on each PersonAddress in the
collection.

At this point, in order to conveniently get the addresses for any given
person (say in an app client), you just write up a method that does the
above. Question being, would people normally put this in a session EJB (a
facade), and hence have to call it like

sessionBean.getPersonAddresses(person)

or put it in the Person class and call it like

person.getAddresses()

Either one works just fine as far as the client is concerned. And to be
honest I prefer the second. I'm just wondering what others would normally
do, and what are the pros/cons of each approach? And I'm certainly open to
the suggestion that I am missing something very obvious...

As an aside, in Linq to SQL in .NET, you pretty much end up doing similar
extra coding when you have a join table (although I understand that the
Entity Framework will improve matters). But at least with that there is no
pretense that Linq to SQL is all that evolved yet.

AHS

 

[Arved Sandstrom]

Can't it do a select on

Person LEFT OUTER JOIN
(PersonAddress JOIN Address ON PersonAddress.address = Address.address)
ON Person.person = PersonAddress.person

?

Presumably yes. I did have a NamedQuery that more or less did this.

I think where I am right now - both with Java EE 5/EJB 3 and also with .NET
3.5/C# 3.0/Linq to SQL - is that since both do so much code generation (I am
obviously assuming that one is using IDEs like Netbeans or Visual C#), part
of the process is actually figuring out what the hell they do _not_ do.

The other thing is that when you do determine that the code generation only
took you so far, and that in order to do a certain thing you do have to
actually code something (Gasp!), there seems to be at least 2 ways of doing
the certain thing, neither of which obviously recommends itself over the
other. The above - to me anyway - is an example of this.

I'm drawing a distinction between stuff like this and the general situation
in all programming languages where (as Perl puts it, TIMTOWTDI...or
TAFTMWTDI) you have multiple ways of doing stuff. In the above cases I am
thinking more of the situation where two major options are thrust right in
your face (for example, Netbeans does generate all the methods for getting
and setting these various collections, *or* you can start writing named
queries to supplement the basic ones Netbeans gave you). As in, which one is
better?

That's pretty much what I meant by "best practices". Maybe there aren't any
yet. Go heavy with the expression language if that floats your boat, or use
conventional methods if you prefer those...

AHS