The design smell is that we use three separate repositories
(or four, if you include the accommodation history dictionary)
and three different data-types. They share nothing:
...
In a real repository pattern implementation, this would be handled
in a very different manner. The interfaces for each data type
would be separate, but behind the scenes they would be refactored
and share data. For example, a single record could represent
ReservationInfo OR AccommodationInfo OR QueueInfo OR
a single "count" in the accommodation history. After all, each
of those data types has SOME of the following elements:
...
... but never all three. So always the same type in a single
table can be used, and viewed appropriately through the prism
of the correct interface:
...
In a real application, the repository would almost always
be implemented via an O/R mapper. Using the O/R mapper, one
would map all of those repositories to the same table – or not.
It does not matter here.
The unrefactored manner of our repository implementation results in
some code duplication, but not for the core
features of the sample application.