Repositories -- sample vs. production
- reinhard reinhard (Unlicensed)
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:
- name
- (room) number
- week
... 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.