Problems with Repository Pattern
Hi! I'm building a booking app (MVP Passive View) for my Software Design course. I'm not allowed to use EF or any ORM—just raw ADO.NET or SQL. My schema:
Client: client_id, name, passNo
Package: package_id, name, price
Seaside/Mountain/CruisePackage extend Package
Reservation: id, client_id, package_id, date
Each reservation has 1 client and 1 package. I need to implement getReservationsByClientId(int clientId).
Client: client_id, name, passNo
Package: package_id, name, price
Seaside/Mountain/CruisePackage extend Package
Reservation: id, client_id, package_id, date
Each reservation has 1 client and 1 package. I need to implement getReservationsByClientId(int clientId).
- Should this method go into ReservationService, and should ReservationRepository do the SQL join and return ReservationEntity with nested ClientEntity and PackageEntity?
- Or should ReservationRepository return only raw IDs, and ReservationService call ClientRepository and PackageRepository separately?
- For converting entities to DTOs, is it okay to create a static EntityToDtoMapper class with separate methods for Client, Package, Reservation, etc.?
- This works for my app, but what if the domain was more complex (like banking)? Is this layered approach still good?
- Would it be better to have a service like ClientReservationService that has all 3 repositories and provides getReservationsForClient()? Or is that an anti-pattern?
- Should ClientEntity contain a list of reservations? If yes, how should ClientRepository load them without creating tight coupling or bidirectional dependencies?