How To Handle Views

In some previous blog posts, I already expressed my empathy towards views and that I use them quite often. I like views, as they are a way to extract information from a database outside of your regular entities. Where if you would want combined information from separate entities, you could fetch them separately and join them in Java, doing it with a view allows you to do all the processing in your database, which saves you some queries and processing in Java. With the separation of DTOs, BDOs and DAOs however, how should you handle views?

In case you are not very familiar with views and don't fully understand the case in which they will be useful, imagine the following case: you want to send an e-mail to all of your customers who made a purchase in the last 2 weeks asking them to review the products. In your database you have a customer entity as well as transactions. In order to have the customer information and the product information you would first have to get all transactions of the last 2 weeks, fetch the related product information (if not duplicated in the transaction) and fetch the customer information (first name, last name, e-mail, ...).

You can either do this by iterating over all transactions doing it one by one, which results in 2*n queries (where n is the amount of transactions), or you fetch all customers and products in the transaction in which case you only have 3 queries, but you end up with a lot of processing in Java to puzzle them all together. What a view allows you to do, is to perform a query with a join and get the wanted information from all tables and map it to an object in Java. While the query may be heavier and slower, you only have to perform 1 and no further processing in Java is required.

From this point of view, it makes sense to put the view on the same level as your DAO, but something isn't really right when you do that. First of all, if you use Spring, a view can easily be implemented as an interface without any Hibernate related annotations. Moreover, a DAO can never be updated as it can not be persisted by Hibernate since there is no mapping to a database. Another questionable result of seeing a view as a DAO would be that you need to map this to a BDO, but this is probelematic as well. Should you have a new BDO for this view? Should you map it to your existing BDOs? But what about missing information?

Mapping it to your existing BDO structure is possible if you fetch enough information, but this again leads to a situation where you are fetching data for the sake of mapping it and not because you need it. A general rule of thumb is that you should limit the amount of data extracted from the database to the bare minimum. For the case I mentioned in the beginning, this means that you would map the view to your Customer, Transaction and Product BDO. Leaving out certain information could cause the creation of the BDO to fail on some sanity check in the best case, in the worst case, you will end up with a BDO that isn't correct. For instance, your transaction may show the product as being given away for free if you didn't fetch the sale price. This can be dangerous if this BDO is used for unintended purposes.

Creating a new BDO object for your views seems redundant at best, since no modifications can be done on this object, or at least it shouldn't be possible since you can't map it back to a DAO and persist it. If you need to perform some changes due to some processing of a view, you should fetch the full DAO, map that one to the BDO, perform your changes and update the DAO accordingly.

If you don't do a mapping to a BDO, can you then consider a view as some special entity that doesn't need any mapping at all? I don't think so, even though I don't have a special BDO for this case, I still believe in having a dedicated DTO for the view. Since a view is still some mapping of data from your database to a Java object, you don't want this information exposed to your clients, and even if you care, you shouldn't want to since this will make changes to the database more difficult ass all changes will cause a change in your API as well.

So I consider views some special object that don't fit in with the DAOs, nor with the BDOs but something that transcends both of them. It is some other type of object that my services can work with. I tolerate this special type of object because I typically only use it for the sole purpose of mapping it to a DTO because the client needs to have this information, or it is required for some other backend process that only needs to read this information (such as the example where you want to send out some e-mails asking for a review).