• Post Reply Bookmark Topic Watch Topic
  • New Topic

POJO Vs EJB what is the best approach

 
Reggie McDougal
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need to get an idea of the best approach to an MVC application I'm developing.

At this point it is simple, a catalog that displays products by using a jsp using a bean to call the method that connect to the database and retrieve the record set in an ArrayList to the jsp and display in a form for editing.

The form then submits to a servlet to write to the database.

Rather than just simply calling a Bean with all my method that retrieve the data I need, based on my simple description of my app would there be any advantage to implementing ejb in my retrieval of reference data and writing it back to the database?

What perceived benefits would ejb give me over the basic simplicity of POJO?

Reg
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35709
408
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reg,
The biggest benefit EJBs would provide in your scenario. Entity beans can cache the frequently requested items which decreases response time under load.

Presumably this catalog if public knowledge and wouldn't require security.
 
Reggie McDougal
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I wanted greater seperation between View and Model would ejb be the best appraoch.

Based on the senario above, using TagLib for display and a controller
to manage requests and utililise ejb to implement the logic.

From an ejb, cause I'm using stored procedures in Oracle I would have to use BMP (from what i have seen CMP and CMR looks like a major pain) now so I can understand ejb a little better, would I even go as far as as session bean to store the data, in this case an ArrayList and a persistance bean to connect with the Intergration tier.

Apart from clear sepeartion using a MVC pattern what other possible advantage gains would I get from taking this approach.

Lets say part of the app is restricted to certain users and other parts public.

Reg
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would add a quote from the book Better, Faster, Lighter Java.

Tool > EJB entities
Suitable for > Nothing
Not Suited for > Sane applications

Tool > EJB (statesless session beans, MDB)
Suitable for > Distributed, transactional facades; Secure, distributed transaction monitor
Not Suitable for > Lightweight applications; Applications where transactions are limited to one database; Facades that are not distributed.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After porting our EJB (stateless session and entity beans with a sprinkle of MDBs) to Spring Framework and Hibernate, I wholeheartedly agree with Steven and the book he quoted -- which I just won from JavaRanch, thanks guys! If you truly need EJBs, my take is that session beans are of higher value than entity beans. And if you insist on using entity beans, definitely tuck them behind a session bean facade and use the Data Transfer Object pattern to isolate them from your web tier (view).

The Data Transfer Object / Value Object pattern is ideal for separating the view from the model. The Business Delegate pattern isolates the usage of session beans from your web tier as well.
[ February 01, 2005: Message edited by: David Harkness ]
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Data Transfer Objects are also an example of why Entity EJBs are a bad thing; since how DTOs are used tend to make them an anti-pattern. You've already populated an object with the values which represent whatever "thing" you are representing with your Entity bean. The only reason why you thn need to copy all those properties over to another object (your DTO) is because you can't pass Entity beans to a client. If the object representing your Entity is a POJO, then you can pass it around to any layer of your app, without having to convert it.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Suitable for > Distributed, transactional facades; Secure, distributed transaction monitor

I like that list, though we might expand it to include some of the other nice container features.

My first EJB app had a bunch of session beans, and after a while we realized that there was only one that was public to external clients and the rest didn't have any reason to be beans. The vendor framework I'm using came to the same conclusion. They have a "gateway" bean that takes all external requests and dispatches them to POJOs, almost exactly like that prior app. We get the advantages of EJB bean pooling, transaction management, security, connection pooling, monitoring, management, etc with only a couple session beans.

Is "one session bean" a common design? It's kinda like the way we use "one servlet" in the servlet container.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!