1

I'm displaying text and xml on a webpage through a servlet. The servlet just loads the HTML/XML to the page on load through calls in the getPost() method. Now that I have that working the way I want it to my next step is to replace the static display text with calls to the database so that it can display information dynamically. My question is:

What is the best way to do this. I'm using JPA and entities for persistence but I have a choice of making direct calls to the persisted items or going through an Data/Entity Access Object which I have created. I followed a tutorial that used EAO's and Entities with EJBs as a way of teaching best practices. I don't see the value in doing this yet, however. It seems overly complicated to go through 3 classes when I could just access the data directly.

So is this the preferred method? or should servlets access data directly or through EAO's?

Thanks

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Randnum
  • 1,360
  • 4
  • 32
  • 48
  • My question probably isn't very clear and I guess I'm really just looking for justification for the way I think it's supposed to be done based on what I've read. I could read on the DAO pattern but I think some one might have a simpler explanation for why going through EJBs and DAOs is beneficial but if the question/answer isn't very obvious I can mark this for deletion :/ – Randnum Nov 08 '11 at 16:13

3 Answers3

4

If you don't need it - don't do it.

Don't introduce additional abstraction layer without a reason. It's just harder to maintain, and if you don't really need it - you'll end with a bunch of dead code (empty delegates).

So, the first step I would do if I were you, I would use the JPA as a persistence layer. It will let you get rid of your additional DAO classes. The EntityManager (you can think of it as an entry point to the JPA) is a Data Access Object itself. Your servlets code should not depend on the database directly, so an EntityManager is a great separation of concerns in your case.

Then you can think of separating your presentation code (Servlet) from the Data-oriented operations. You could do that by using i.e. a CDI and implementing this logic in simple POJOs. This will let you (Servlet) not to depend on the code used for fetching or transformation of your data. Your servlet will typically just 'get the data' (it doesn't have to know where from it come).

Use EJBs if you need services they introduce (transactionality, thread-safety, timers, asynchronous calls, additional entry-points like SOAP or REST Web Services, JMX access, pooling, ...).

HTH.

Piotr Nowicki
  • 17,914
  • 8
  • 63
  • 82
  • Thank you, I would love more information on these types of topics. Right now as a new student of JEE I feel like I'm probably using EJBs unnecessarily when I could be using a POJO. Can you use CDIs with POJO's? Right now I have a session bean that I use to handle of of my "business logic" which really isn't logic but just calls to my DAO, and any other major execution blocks/classes that I have. It's almost like a dispatcher/interface because then I only have inject that bean into my servlet and I can reference any method in my project. – Randnum Nov 08 '11 at 16:42
  • @user988231 if it comes to the CDI just take a look at the Weld (implementation of the CDI) documentation: http://docs.jboss.org/weld/reference/latest/en-US/html/ - it's really great source of knowledge. – Piotr Nowicki Nov 08 '11 at 16:46
  • Although I'd probably like to eventually make a lot of these calls asynchronous so as I add functionality the necessity might become more apparent. – Randnum Nov 08 '11 at 16:46
  • Well, don't get me wrong - an EJB is still a POJO (as you know you just annotate the class `@Stateless`, `@Stateful`, etc.) If your logic is very a simple CRUD than you can create a generic service and just extend / implement it. – Piotr Nowicki Nov 08 '11 at 16:50
  • @user988231 exactly that's the point. If you need an asynchronous access you'll see the added value of using EJBs. Soon as you'll start using the EntityManager you'll see another added value - container-managed transactions which will save you from explicitly coding them. – Piotr Nowicki Nov 08 '11 at 16:52
1

There are different factors, it is useful to know both approaches.

EJB's are simpler and have a lot of features for transaction management. Without EJB the code to persist would be more verbose.

Maybe this will help to understand better.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

r0ast3d
  • 2,639
  • 1
  • 14
  • 18
1

Whether or not use DAOs should be done in a per use case basic IMO.

Following a link to an answer that could help you figuring this one out.

How should EntityManager be used in a nicely decoupled service layer and data access layer?

Community
  • 1
  • 1
Gonzalo Garcia Lasurtegui
  • 4,911
  • 5
  • 32
  • 49