Is it a good practice to embed behavior into Entity Beans?

Question

While my Java apps were small and did simple things, I was quite happy using plain SQL, all the more that application servers like Glassfish make connection management really easy. After I learned about JPA and EJB, I decided to refactor my projects to make them use these cool things, but faced an issue that is more about design than programming:

Is it a good practice to embed behavior into Entity Beans, or they should only hold data?

I've read many manuals and tutorials, but they mostly answer how I can use them, not how I should, to meet good-design requirements.

For example, given 2 classes: User and Location, they are both entity beans. A user can store collection of locations, and it's OK and easy to implement using JPA. But if I want to populate these classes with some functionality, such as methods for calculating distance to another user or location, finding their paths intersections, calculating distance that a user ran over a day, and so on. Would it be a "good design" if I implement such functionality in beans themselves or I should use special decorators and helper classes with plenty of static methods to achieve my goal?

Answer 1

You are trying to implement a Domain Driven (DD) approach. It is useful for some applications, but tends to be opposed to SOA architectures. SOA concepts are widespread, highly proven and even it's a hot topic right now, see also microservices (a.k.a SOA v2.0)

If you are using Java EE, you can use a Gateway pattern to implement DD or Boundary-Control-Entity for SOA.

Now some points:

• Is it a good practice to use Entity Beans as usual objects, not only as data representation?. For DD it's ok and encouraged. For SOA, not.

• Will a DD design scale better than a SOA?. Depends on the application (the memory footprint of a Stateful bean is small and manageable). Only a stress test will give you good insight.

• Can I create a prototype based on DD and then pass to a SOA if needed?. Why not?, there is maybe a hard refactor phase, but is possible. DD prototypes are faster to build.

• Any security issues worth to mention in relation to immutable objects?. Immutable objects are about avoid concurrency issues (nothing to change, no one gets hurts). Gateway pattern is based on transactions and EJBs (with the inherited security model). So in general, no issues.

• Do I need gets/sets with JPA?. No, are not mandatory.

• Can I create Immutable objects with JPA?. Yes, just a constructor and private attributes (correctly annotated) and done.

• Can I mix some behavior in the entities of a SOA project?. Well, I will just add some specific methods that does not require add an entity manager to the entity, that means, simple operations that not work over a huge graph of objects. Consistency accross the project is very important.

• What about testing?. Both solutions are highly testable. Altough SOA and microservices forces you to break your app in tiny pieces which may help you to avoid creating a monolithic (big ball of mud) application.

I hate how bad endemic models looks, but well, at least works.