JPA双向关系与存储库/ DAO的使用

Question

i`m struggling myself since a while about this. I have an entity graph with 30 entities. Most of them are connected through bidirectional relationships. Some connections are very useful and some not, because they only serve the convenience in case of deletions between the entities.

Furthermore I have repositories to create/find/store the entities. Unfortunately there is a repository for every entity and it feels like, that these repositories are windows into my object graph. Is such thing a recommended implementation?

Because of the boiler plate code caused by the bidirectional relationships maintaining the parent/child associations I had the idea to replace some of these bidirectional relationships and put this into the repository. Some of these relationships are only useful in conjunction with further parameters. Lets take the classic Customer <-> Order example. I think that the direction Customer -> Order is not always good, because sometimes there is a need to limit the result to a specific period.

My question is: What do you recommend to get out of this struggle? Do you always use bidirectional relationships in bigger projects for the convenience? Or do you replace them with specific repository queries? Is it okay to maintain repositories for every entity?

I'm torn for a while... :-(

Answer 1

Well, in my opinion, it's difficult to say without knowing a little more about your setup. Are you using Spring CrudRepositories , custom Daos or EntityManager? Perhaps it doesn't make that much of a difference, but I wonder about it.

In short, I was perfectly happy writing an application recently that had 10 or so Enities and only one service layer. Perhaps it can help to think about business needs and start crafting a new service layer. Despite having 30 or so entities, you may only have a handful of business points of view. Customers, obviously, and Orders. Also, probably, Payments, Shipping, Returns.

Look at who is using the application and what do they call their departments. Make a service for that department. Put a call for every need for that department, even if you are duplicating some code from other departments. Don't forget the IT department. Later, when you get a good idea of how these services are shaping up, you can factor out common actions.

Hope this helps.