Should JPA Entities Contain Business Logic? ...Why Not?

It is one of the classic FAQs: "Should I put business logic into JPA entities?" I guess the doubts originate from the old CMP 2.X days. Entity Beans were neither powerful, nor clean enough to be considered as domain object candidates. The dependency on the technology was heavy - on the other hand even inheritance wasn't supported. It was a common best practice to factor out the logic into the service layer. This led to procedural code - at least the business logic wasn't polluted with the technology...

With the advent of Hibernate and especially JPA, the weaknesses, and so the actual reasons, for the artificial separation of logic and state were basically eradicated. JPA entities are nothing but Java classes without any direct dependency on the particular technology (except of some runtime dependencies on weaved-in code), so there is no more reasons to keep them enemic. In fact I tend to answer the question with another question: "Why not? What can happen in worst case putting the logic into persistent entities?" There are some caveats doing so:

  1. If the entities are used as transfer objects as well, the client could invoke the methods what could change the whole graph. This could be hard to merge back.
  2. The logic of a domain object should really belong to it. Otherwise you could get lots of conditional code caused by the violation of seperation of concerns. There should be no client specific logic in the entities. Client-specific functionality should be factored out somewhere else... 

On the other hand good domain objects are clean, concise and easy to test and maintain. There is no bloat caused by the artificial separation of state and behavior. On the other hand, actually nothing is transparent :-).

See also:

Different Persistence Styles - and there is no single truth

Are your objects anemic? It's time to get rich...

[This post was motivated by this off-topic comment :-) ]

NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: and newsletter:

A book about rethinking Java EE Patterns


It just feels wrong to put business logic into the model or dao layer unless that logic pertains to the business of data gathering. Perhaps your data comes out of a database as a Set and you want it to be returned as a TreeSet. That would be okay.

I would be in favor if the model and dao layer were combined but I think it is a bad idea to put business logic into the model layer. Doing so constrains your model to business specific problems.

Maybe for small projects that will never be reused it would be okay. But as a rule I still tend to shy away from it.

Posted by jkilgrow on February 19, 2009 at 05:05 PM CET #

Isn't that what domain driven design pushes? Putting business logic in the model?

Posted by Ryan on February 20, 2009 at 01:24 AM CET #

"Doing so constrains your model to business specific problems" - that's exactly what your model stands for: describing and encapsulating your business' domain data and logic.

Posted by Kristof Jozsa on February 20, 2009 at 09:09 AM CET #

And if you want to program with naked objects you have too.

Posted by Christian on March 01, 2009 at 02:19 AM CET #

Yep, classic quandary: you want to encapsulate the logic, but not incur the baggage (eg, your DTO issue).

I think we have come up with something you might find interesting. We plug a "logic engine" into Hibernate, and execute declarative (spreadsheet-like) logic you supply in "companion classes" that correspond to your entities. This resolves the quandary, and lends quite a bit of agility.

Posted by Val Huber on June 10, 2011 at 01:42 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments