Child pages
  • Repositories -- sample vs. production
Skip to end of metadata
Go to start of metadata

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.

  • No labels