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).
1. Should this method go into ReservationService, and should ReservationRepository do the SQL join and return ReservationEntity with nested ClientEntity and PackageEntity?
2. Or should ReservationRepository return only raw IDs, and ReservationService call ClientRepository and PackageRepository separately?
3. For converting entities to DTOs, is it okay to create a static EntityToDtoMapper class with separate methods for Client, Package, Reservation, etc.?
4. This works for my app, but what if the domain was more complex (like banking)? Is this layered approach still good?
5. Would it be better to have a service like ClientReservationService that has all 3 repositories and provides getReservationsForClient()? Or is that an anti-pattern?
6. Should ClientEntity contain a list of reservations? If yes, how should ClientRepository load them without creating tight coupling or bidirectional dependencies?
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).
1. Should this method go into ReservationService, and should ReservationRepository do the SQL join and return ReservationEntity with nested ClientEntity and PackageEntity?
2. Or should ReservationRepository return only raw IDs, and ReservationService call ClientRepository and PackageRepository separately?
3. For converting entities to DTOs, is it okay to create a static EntityToDtoMapper class with separate methods for Client, Package, Reservation, etc.?
4. This works for my app, but what if the domain was more complex (like banking)? Is this layered approach still good?
5. Would it be better to have a service like ClientReservationService that has all 3 repositories and provides getReservationsForClient()? Or is that an anti-pattern?
6. Should ClientEntity contain a list of reservations? If yes, how should ClientRepository load them without creating tight coupling or bidirectional dependencies?
