EJB的简单但良好的模式

Question

What would you suggest as a good and practical but simple pattern for a solution with:

• HTML + JSP (as a view/presentation)
• Servlets (controller, request, session-handling)
• EJB (persistence, businesslogic)
• MySQL DB

And is it necessary to use an own layer of DAO for persistence? I use JPA to persist objects to my DB.

Should I withdraw business logic from my EJB? All online sources tell me different things and confuses me...

Answer 1

I would definitely put the business logic in Stateless Session Beans. Stateless session beans are nice as they nicely capture the transaction boundaries. And it decouples the View layer from the persistence layer.

Take care that the methods of the SSB correspond to small business goals the user wants to achieve.

Another point is that you must be sure that the data you return has all data in the object tree and that you do not rely on lazy loading to get the rest, because this causes all kind of problems.

Stay as far away as possible from Stateful Session Beans : they are bad news and are a broken concept in the context of a web application.

For long running things, consider using Message Driven Beans which you trigger by sending a JMS message. These are a nice way to do background processing which frees the business logic faster, keeps transactions shorter and returns control to the end user faster.

Answer 2

What would you suggest as a good and practical but simple pattern for a solution with JSP/Servlets + EJB + MySQL

Use the MVC framework of your choice, Stateless Session Beans for the business logic and transaction management (prefer local interfaces if you don't need remoting), Entities for persistence.

Inject your EJBs wherever possible (if you are using Java EE 6, this means anywhere and you can also skip the interface).

And is it necessary to use an own layer of DAO for persistence? I use JPA to persist objects to my DB.

Some might say yes, I say no in most cases. The EntityManager already implements the Domain Store pattern, there is no need to shield it behind a DAO for simple needs .

You might want to read the following resources for more opinions on this:

• Has JPA Killed the DAO? ,
• JPA/EJB3 killed the DAO ,
• and the more recent DAOs Aren't Dead - But They Either Collapsed Or Disappeared

Should I withdraw business logic from my EJB?

I wouldn't. Put your business logic in your (Stateless) Session Beans. EJB3 are POJOs, they are easily testable, there is no need to delegate the business logic to another layer.

Answer 3

Anno 2012 I would not recommend going for Servlets and JSP as the presentation layer. This was all the rage in 2002, but that's a decade ago.

Today Java EE has an excellent MVC framework build in called JSF. You are much better off using this instead. You most likely want to fetch some Widgets from the component library PrimeFaces, as all the standard ones are a bit basic. A utility library like OmniFaces is a great addition as well.

Regarding the DAOs; don't go as far as directly using the entity manager in (JSF) backing beans, but if you are already using Service classes (transactional boundaries) for your business logic , using a DAO as well might be overkill.

There are still some small advantages of a DAO, like a dao.findByName(...) looks a little clearer than loading a named query, setting a parameter, and getting a (single) result, but the cost is that you have to maintain a seperate DAO for each Entity, probably in addition to some Service.