Is it good practice to implement behavior in Entity Beans?

Question

Although my Java applications were small and did simple things, I was quite pleased with the use of simple SQL, especially since application servers such as Glassfish simplify connection management. After I learned about JPA and EJB, I decided to reorganize my projects so that they use these cool things, but ran into a problem that is more related to design than programming:

Is it good practice to embed behavior in Entity Beans, or should they only store data?

I read a lot of manuals and manuals, but they basically answer how I can use them, and not how I should meet the requirements of good design.

For example, if 2 classes are specified: User and Location , they are both beans objects. A User can store a collection of Location s, and this is normal and easy to implement using JPA. But if I want to fill these classes with some functionality, for example, methods of calculating the distance to another user or location, find their intersections, calculate the distance that User ran for a day, and so on. Will it be a “good design” if I implement such functionality in beans myself or should I use special decorators and helper classes with many static methods to achieve my goal?

Answer 1

You are trying to implement a domain-driven approach (DD). This is useful for some applications, but is generally contrary to the SOA architecture. SOA concepts are widespread, highly tested, and even now are a hot topic, see also microservices (aka SOA v2.0)

If you use Java EE, you can use the gateway pattern to implement DD or Boundary-Control-Entity for SOA.

Now some points:

• Is it good to use Entity Beans as regular objects, and not just as a representation of the data. For DD, this is normal and recommended. For SOA, no.

• Will DD design scale be better than SOA? . Depends on the application (memory size in Stateful bean state is small and manageable). Only a stress test will give you a good idea.

• Can I create a prototype based on DD, and then, if necessary, go to SOA? Why not? There may be a difficult refactoring phase, but it is possible. DD prototypes are faster to create.

• Any security issues worth mentioning regarding immutable objects. Inevitable objects bypass concurrency problems (don't change anything, no one gets pain). The gateway template is based on transactions and EJBs (with an inherited security model). So no problem at all.

• Do I need to receive / sets with JPA ?. No, not necessarily.

• Can I create immutable objects using JPA? Yes, just the constructor and private attributes (correctly annotated) are done.

• Can I mix some behavior in SOA project objects? . Well, I'll just add some specific methods that don't require adding an entity manager to the entity, which means simple operations that don't work on a huge graph of objects. Project coherence is very important.

• How about testing ?. Both solutions are highly verifiable. Moreover, SOA and microservices make you break the application in tiny pieces, which can help you avoid creating a monolithic (big ball of dirt) application.

I hate how bad endemic models look, but at least it works.

Answer 2

I think that you should not include all these logical methods in your organization, perhaps the best way is to get it from the business level.

It is never good to get a lot of time fields on our entities, so perhaps the best way is to create VO (Valued Object) classes.

Using VO also solves the problem of encapsulation, since setters are not needed.