If you are a programmer, you have dealt with persistence layers in many senses:

And if you are a programmer, you know that all those persistence layers have to be abstracted from the application's business logic. There are several techniques to achieve this:
All those techniques wrap your data from the persistence source you are using, because your application should have its own 'language'.

Why?

Because each application is meant to solve a specific problem (or a set of problems), and that problem has a domain, and that domain will be used as basis during the development/maintenance phases. During these phases you might have different people working with the same code. So, the developers will need to understand what they are modifying in order to add/remove/fix specific parts of the system.

This is the point where documentation and comments become important, I also take a deep look at the context applied to the programming, I mean, class names, attribute identifiers, method names, etc.

All these things give the source code a meaning, what can you say from this?


and what about this?


which one is more verbose? which one has more meaning? which one would you prefer to have in your source code?

Even though the first chunk of code uses JPA, it is verbose enough, the second one really does its job, you don't need to know whether you are using a database or not and it is really easy to read, if you want to modify a condition or change the behavior you just go to the specific method, and that's it!