Does it have to be transactional ? What about security ?
Jonathan Aotearoa wrote:The point is you're not going to be calling that business logic directly; you're going to be invoking it via a session bean ...
The detached entity may also have been updated in the mean time in which case the merge will overwrite any changes done by another user.
. However, the "business behavior" shown in this book is "limited" to getters and setters.
A rich domain model on the other hand, encapsulates both object attributes and behavior and utilizes objected oriented design such as inheritance, polymorphism and encapsulation.
The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters.
Jonathan Aotearoa wrote:The problem with having JPA POJOs for you domain model in an EE environment is that you can't inject an entity manager into them
Jonathan Aotearoa wrote:The problem with having JPA POJOs for you domain model in an EE environment is that you can't inject an entity manager into them. That means your domain model objects can't even do the basics like persist themselves. People get round that by introducing a service layer made up of stateless session beans. The result is an anemic domain model with lots of transaction scripts.