Data Mapper API - unsure about organisation

Let's say we have "User" and a "Hotel" model classes. I'd use a User_Mapper and Hotel_Mapper to load/save/delete etc. I want to then have the user be able to mark their "favourite" hotels. In the database I have my user_favourite_hotels table which is a simple link table along with say a field for subscribing to hotel updates.

When listing out the user's favourite hotels, how would 开发者_如何学JAVAyou expect this to work from an API point of view? A part of me thinks that this should be a "findFavouritesByUserId" method on the Hotel_Mapper, but other than saying it "feels" right - however a colleague suggests that the "favourites" is owned by the user and should therefore be on the User_Mapper.

Perhaps I should have a User_Hotel_Favourites_Mapper? I was thinking of incorporating the "favourites" data in to the User object so it's saved and loaded whenever the User object is. I'm not sure whether it'd be better to split it out in to it's own object and mapper however.

I'd appreciate any advice on how best to setup the API for the above and any pros/cons/experiences.

Thanks very much,

James.

This (admittedly retired) patterns&practices guide to designing data tier components suggests that you put the method in the mapper of the type of object that you're getting back from the call.

If you have methods that return a particular type of business entity, place these methods in the Data Access Logic Component for that type. For example, if you are retrieving all orders for a customer, implement that function in the Order Data Access Logic Component because your return value is of the type Order. Conversely, if you are retrieving all customers that have ordered a specific product, implement that function in the Customer Data Access Logic Component.

So, in your example, it would go in the Hotel Mapper as it is returning Hotels.

If you want to store favorite hotels for the user, you are using the UserMapper, which notices that domain object for User has changes favorites, and updates both tables for users and for user_favorite_hotels ( you just need the hotel IDs ).

When you are retrieving favorite hotels of some user, you use HotelMapper and set filter to be based on User, because you will be working with instances of Hotel.

Considering that this was asked more than 2 years ago, I'm not sure if an answer matters to you now. But here's what I think anyway.

If User could have multiple types of favourites (including Hotels), it may make sense to have a UserFavourites abstraction to cover all possible types of favourites. UserFavourites could expose a getItems() method to get the underlying Favourites.

This could be managed with the help of a manager class to return the appropriate Favourites object(FavouriteHotels for example) on which the getItems() method can be called.