Representation layer

After the data has been processed and persisted in a database, there must be a way for users to retrieve the data from the system. The stakeholders have said that they would like an API so they could hook up external applications to it easily. With this in mind, we shaped the representation layer as follows:

The API is the point the web application, reporting engine, Eclipse plugin or anything can communicate with in order to retrieve data from the database. This doesn’t contain any logic itself, but just handles the requests and delegates the work to the underlying Query Consolidator service that in turn communicates with the database via a data access layer.

Since the API was a requirement and the data access layer is a standard way of separating the application logic from the database access the only thing that really needed to be decided was whether to make the Query Consolidator separate from the API or not. This too, is standard in application development. Controllers should not contain any logic; this is a task for the services.