Open Session In View Pattern

Open Session in View has some problems.

For example, if the transaction fails, you might know it too late at commit time, once you are nearly done rendering your page (possibly the response already commited, so you can’t change the page !) … If you had know that error before, you would have followed a different flow and ended up rendering a different page…

Other example, reading data on-demand might turn to many “N+1 select” problems, that kill your performance.


Many projects use the following path:

  1. Maintain transactions at the business layer ; load at that point everything you are supposed to need.
  2. Presentation layer runs the risk of LazyExceptions : each is considered a programming error, caught during tests, and corrected by loading more data in the business layer (you have the opportunity to do it efficiently, avoiding “N+1 select” problems).

To avoid creating extra classes for DTOs, you can load the data inside the entity objects themselves. This is the whole point of the POJO approach (uses by modern data-access layers, and even integration technologies like Spring).

Leave a Comment