Sorry about the many abbreviations in the title... My observation is that applications built with an object-relational mapping like Hibernate tend to follow a service-oriented architecture instead of an object-oriented one.
Some people (e.g. here) say the Single Responsibility Principle suggests that dealing with reading/writing attributes of persisted objects as well as creating and finding these objects is enough responsibility for one class. Any business logic using such an object should go to separate classes. That leads us to a design with two separate types of classes: state-full but dumb record keeping ones, and logic bearing but state-less ones.
Here's why I don't like this kind of design:
(1) To me, this separation of data and code is not a goal of object-oriented but is the design of service-oriented architecture. OOD says that operations should go to the classes where the attributes it uses are defined at.
(2) Also, it's a bogus solution: whenever the structure of one of the state-full classes changes, I'll have to change all the service classes that use it, too. If I had the logic inside those classes, the change would stay in one class.
(3) I'm using an ORM framework which pretty much generates all the code necessary for accessing the persisted data for me into a class. If I wasn't adding the business logic to it, the class would stay rather "empty", i.e. it would contain the generated code only.
I know that many programmers follow the service-oriented design, especially when using frameworks that suggest this, like Spring. If I were using such a framework, I'd go with the separation of code and data, too.
I don't want to provoke a discussion whether SOA is good or not. I'm interested in the question whether it's good OOD (as per SRP) to separate business logic from classes representing entities.