Why should the Director be a bean? Why can’t it just be data?
Why not have the Movie bean simply go to the database, using the Director’s foreign key (stored as a persistent field in the Movie bean), and get the Director’s data? But if you make the director a bean as well, you get to think ONLY in objects (except during deployment, when you do have to map from your beans to your tables). And you get all the benefits of container-managed persistence and synchronization. Imagine if someone calls a setter method to change the director’s oscar winning status. If you’re managing this, you’d have to get a JDBC connection and synchronize the database yourself. And of course, you’d have to know when is the right time, etc. But if its director is also a bean, you call a setWinner() method, and you’re done.
Oh, and there’s another cool thing. You might decide, for example, to banish a specific director from your database, because you think his movies suck in an unrecoverable way. No problem deleting that director, obviously. But then what happens to the movies? How can you have movies in the database that don’t have a director? What is the database is already set up in such a way that you aren’t allowed to have a null value for the director column? In other words, what if a movie cannot exist in the database without a director?
You can handle this brainlessly, by setting up the Movie-to-Director bean relationship in such a way that when you delete a director from the database, all of his movies ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access