JavaEE app structure

Question

I'm creating a web app using JEE7. My question is about the architecture of my application. Basically, I have several entity classes (business class) that represent what will be stored in my database. For example I've got an entity class Book and an entity class Comic.
To access the database I want to create an EJB (kindda like the DAO design pattern). And here is my problem, I couldn't find a precise answer online.

Should I create one @remote interface and one @stateless class with all the methods to add/delete/get/update for both the Book class and the comic class ?

Or should I create 2 @remote interfaces and 2 @stateless classes (2 EJB), one for each entity class ?

Because lets imagine I create a bigger web app. If I have 100 entity classes, with the first method I'll have one huge EJB but with the second I'll have 100 EJB with their interfaces. I think the second is better but I'm not sure. What do you think ?

Answer 1

Why not just use one stateless bean and one remote interface?

A very nice feature of remote beans is, that they can be generic, so basically at minimum you only need one interface and one remote bean at all (see SimpleEntity and its remote bean).

I use a mix of a very generic remote bean DAO to read simple entities and some specific beans for entities which need more logic on CUD operations. Following i just extracted the minimum interfaces to reproduce it.

If i create a new table and entity it can immediately be used at the remote client.

Entities

/* 
 * Complex entity with enhanced CRUD logic
 */
public class Foo implements Entity { }

/*
 * Simple entity without complex CRUD logic
 */
public class Bar implements SimpleEntity { }

Interface

public interface Entity { }
public interface SimpleEntity extends Entity { }

/*
 * Generic entity DAO interface, for remote beans and other datasources
 */
public interface IEntityDAO<T extends Entity>
{ 
    public T get(Class<T> type, long id);
    public T update(T t);
}

/*
 * Generic remote bean interface for a JNDI service locator lookup
 */
public interface EntityDAOBeanRemote<T extends Entity> extends IEntityDAO<T> { }

Stateless remote Beans

/*
 * 'abstract' base class for stateless DAO beans
 */
public class AEntityDAOBean<T extends Entity> implements EntityDAOBeanRemote<T>
{
    public T get(Class<T> type, long id)
    {
        Session session = // obtain current hibernate session
        return id == (T) session.createCriteria(type).add(Restrictions.idEq(id)).uniqueResult();
    }

    public T update(T t, long id)
    {
        Session session = // obtain current hibernate session
        session.update(t);
        return t; // return updated instance
    }
}

/*
 * Generic stateless remote DAO bean implementation
 */
@Stateless(mappedName = "SimpleEntityDAOBean")
@Remote(EntityDAOBeanRemote.class)
public class SimpleEntityDAOBean extends AEntityDAOBean<SimpleEntity> implements EntityDAOBeanRemote<SimpleEntity>
{
    // empty since all methods are from parent class
}

/* 
 * Foo specific remote DAO bean
 */
@Stateless(mappedName = "FooDAOBean")
@Remote(EntityDAOBeanRemote.class)
public class FooDAOBean extends AEntityDAOBean<SimpleEntity> implements EntityDAOBeanRemote<Foo>
{
    @Override
    public Foo update(Foo foo) 
    { 
        // make specific foo things and update
        return foo;
    }
}

Client

Using JNDI at your client you can call the bean using a JNDI service locator pattern like:

    EntityDAOBeanRemote<Foo> fooDAOBeanRemote = jndiServiceLocator
        .getEntityDAOBeanRemote(Foo.class);

    EntityDAOBeanRemote<Bar> barDAOBeanRemote = jndiServiceLocator
        .getEntityDAOBeanRemote(Bar.class);

Client JSF

With generic JSF converters and a generic extension of a DAO for a GUI framework (such as PrimeFaces LazyDataModel) it saves a lot of time making new entities quickly accessible in JSF beans and editable in the GUI.

Answer 2

Java EE application architecture is obviously a massive topic, but a common approach would be to create a Session EJB to expose general API calls to your client and then use a coarse grain Entity EJB to handle your persistent data. These Entity EJBs can manage a number of finer grained Java objects and classes that map onto your database structure.

This might be a good place to start: https://docs.oracle.com/cd/A87860_01/doc/java.817/a83725/entity1.htm