When should I use POJOs (not EJBs) in Java EE applications?

I am currently learning Java EE I use Oracle Java EE 7 tutorial According to section 34.1.1 of this tutorial In Section 4, they used some non EJB auxiliary classes in the tutorial examples http://docs.oracle.com/javaee/7/tutorial/doc/ejb-basicexamples001.htm

I want to know when I should create an EJB class and when I should use the usual helper class I've seen the benefits of using EJB But is it better to use POJO?

Solution

Managing EJB components (managed by containers) means some extra overhead Fly has an anti pattern called sledgehammer:

EJB (a technology with extra overhead) is selected on a simple POJO, which only needs lightweight processing Generate additional complexity; No obvious benefits

Solution:

If your code does not use the following container services, use POJOs:

>Concurrency > entity interaction > interceptor > Lifecycle Management > timer > transaction management

I would like to add that in many cases, EJBs are used like service facades / services There are real scenarios when you want to use design patterns (CDI objects or POJOs) to process business logic instead of just using EJBs to place logic in a procedural manner Redefine: the EJB service facade is a single entry point for design patterns that address complex business requirements (if you don't need a design pattern, don't use it, keep it simple!)

Source: Flying sledgehammer, service facade, service:

OCM Java EE 6 Enterprise Architect

Real World Java EE Patterns–Rethinking Best Practices