API Data Mapper: no está seguro de la organización

Question

Digamos que tenemos clases de modelo "Usuario" y "Hotel". Yo usaría un User_Mapper y Hotel_Mapper para cargar/guardar/borrar, etc. Quiero que el usuario pueda marcar sus hoteles "favoritos". En la base de datos tengo mi tabla user_favourite_hotels que es una tabla de enlace simple junto con un campo para suscribirse a las actualizaciones del hotel.

Al enumerar los hoteles favoritos del usuario, ¿cómo usted espera que esto funcione desde un punto de vista de la API? Una parte de mí piensa que esto debería ser un método "findFavouritesByUserId" en el Hotel_Mapper, pero aparte de decir que "se siente bien", sin embargo, un colega sugiere que el "favorito" es propiedad del usuario y, por lo tanto, debe estar en el User_Mapper.

Tal vez debería tener un User_Hotel_Favourites_Mapper? Estaba pensando en incorporar los datos "favoritos" en el objeto Usuario para que se guarden y carguen siempre que sea el objeto Usuario. No estoy seguro de si sería mejor dividirlo en su propio objeto y mapeador sin embargo.

Agradecería cualquier consejo sobre la mejor manera de configurar la API para lo anterior y cualquier pros/contra/experiencias.

Muchas gracias,

James.

Answer 1

Esto (admitidamente retirado) patterns&practices guide to designing data tier components sugiere que coloque el método en el asignador del tipo de objeto que está recibiendo de la llamada.

Si tiene métodos que devuelven un tipo particular de entidad comercial, coloque estos métodos en el Componente Lógico de Acceso a Datos para ese tipo. Por ejemplo, si está recuperando todos los pedidos para un cliente, implemente esa función en el Componente lógico de acceso a datos de pedido porque su valor de retorno es del tipo Pedido. Por el contrario, si está recuperando todos los clientes que han pedido un producto específico, implemente esa función en el componente lógico de acceso a datos del cliente.

Por lo tanto, en su ejemplo, iría al Hotel Mapper ya que está devolviendo hoteles.

Answer 2

Si desea almacenar los hoteles preferidos por el usuario, se utiliza el UserMapper, que da cuenta de ese objeto de dominio para User tiene cambios favoritos y actualizaciones de ambas tablas para los usuarios y para user_favorite_hotels (que sólo necesitan los identificadores de hoteles).

cuando esté recuperando hoteles favoritos de algún usuario, se utiliza HotelMapper y conjunto de filtros que basarse en User, ya que va a trabajar con instancias de Hotel.

Answer 3

Considerando que esto se formuló hace más de 2 años, no estoy seguro si una respuesta es importante ahora. Pero esto es lo que pienso de todos modos.

Si User puede tener varios tipos de favoritos (incluyendo Hotel s), puede tener sentido tener una abstracción de UserFavourites para abarcar todos los tipos posibles de favoritos. UserFavourites podría exponer un método getItems() para obtener los Favoritos subyacentes.

Esto podría administrarse con la ayuda de una clase de administrador para devolver el objeto de Favoritos apropiado (FavouriteHotels por ejemplo) en el que se puede llamar al método getItems().