Hi all,
Which is good approach for a web based application


1. Servlet ----> EJB (session Bean)---->Hibernate ---> Database

2. Servlet ---> Hibernate---> Database

---> means "call to "


Thanks
rbarun

Assuming your EJB (session bean) is referring to a remote session facade, with this approach you will have to deal with serializing objects you wish to return to the client (servlet). We are looking at this approach for a project I'm working on, and this is a major concern for me, as eagerly loading some of our objects would be a bit... overkill (read: my DBA will murder me and bury me in her back yard ;)).

Anyway, another thread mentioned that ch. 8 of Hibernate in Action had some discussions on layered architectures such as this, so I am very impatiently waiting on Books-a-Million to get my copy to me :-)

There's also some discussion of this in the patterns section of the wiki, though I haven't had time to really dig into it yet.

Neither... I like:

Servlet (display only) ----> Middle App Layer with logic ---->Hibernate ---> Database

It's a little hard to show in a line, but best to have the EJB as the information carrier, but have no logic.

Servlet gives middle layer EJB with data,
Middle layer processes and calls Hibernate to store or fetch,
Hibernate returns EJB to Middle layer,
Middle layer does any post-processing and returns the EJB to the Servlet for display

But, that's one programmer's opinion. Depending on how complex your app is, you can extend on the middle layer a lot.

I'm sorry, I'm a bit confused:



Where are the EJBs you're referring to? Are you talking about entity beans or SLSBs? If entity, how does hibernate fit into this picture? I would picture hibernate as actually replacing entity EJBs.

However, I guess I could see something like

Servlet ----> EJB (session Bean)----> Middle App Layer with Logic (command pattern?) ----> Hibernate ---> Database

Where your session facade basically provides little more than an RMI interface and transaction demarcation. If your business logic is not too terribly convoluted, though, I don't see much advantage in this over simply placing that business logic directly in the Session Facade layer.

What's a session facade? I'm just saying that beans should really be just that, data containers. They should really not ever have any logic. They should be passed from one place to the next to contain information. If --> denotes calling (which I interpret as a something that does something, not just get and set), EJBs don't really belong on that diagram unless you want to say:



Hibernate doesn't replace beans because you still write a bean that Hibernate uses. It is possible to detach the bean from the DB session, use it in the servlet, and then reattach it to the session. But the session stuff and all logic should be in the main part of the app, not in the servlet, IMHO.

But this is just how I see things. There is always room for dissention.

I think we are speaking in different terms. A bean (IMO) describes any java object that conforms the JavaBeans design conventions. An EJB, however is a managed Enterprise JavaBean (i.e. implementing several of the interfaces in javax.ejb.*) and must run in a managed environment (EJB Container). (Of course, Enterprise JavaBeans are also expected to follow the JavaBean design conventions, but there's much more to it than that.)

For information on the Session Facade design pattern, see http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html

To be accurate, I see hibernate as replacing EJB Entity Beans with the Transfer Object design pattern, where the Transfer Objects would correspond roughly to transient or disconnected POJOs making up a domain model in hibernate.

You seem to be equating EJB to the hibernate concept of entities, which are POJOs (presumeably which follow the JavaBean design conventions) that are persisted and are associated with a hibernate session. The concepts are similar conceptually, to be sure, but they are not the same.

Plenty of skilled programmers have written successful web apps using different designs. Which layers you use, and what they do, depends on the size and needs of your app. Experience and thoughtfullness are the best guides.

That said, I'd start with servlet -> service class -> Hibernate. All three layers use your domain objects.

By "service class" I just mean a simple Java class that encapsulates your application's business logic in methods like:

public Employee find(String name) {
// Get Hibernate session
// Create Hibernate query
// Run Hibernate query
// return query results
}

public void deleteEmployee(String name) {
// call Hibernate to delete employee
}

This separation of concerns is useful even in small apps, and can scale nicely with many different frameworks.

I wouldn't bother with EJBs unless you are forced to use them. They are rarely worth the trouble.

Try coding your project with just plain servlets and Hibernate code, then look into the Spring framework. Spring makes it easier to work with Hibernate. The Spring sample web apps lay out a nice, simple design as well. The downside, of course, is you have to learn Spring as well as Hibernate.

Finally, think about using Spring MVC, Tapestry, WebWork, or Struts in place of servlets alone. Any app beyond the smallest can benefit from a good web MVC framework.

Ok, that's definitely where we were breaking down in communication! I didn't realize that EJBs were actually something other than a bean. Bean to me always means POJO. Makes sense when you explain it that way.

I still like the idea of the middle layer having the business logic and keeping that out of your beans. But everybody likes different things! And different design patterns are good for different uses, which is why there are so many of them.

I'll have to read more about Session Facade, now you've got me curious.

Session facade is quite useful, especially if you expect to need to cluster your servers or provide access from one application into another through something other than the database itself. In our case, we are planning to use a Session Facade to present a remote interface to the model portion of an application that other applications will need access to. The facade will also provide business rule validation and encapsulate our business logic. In that manner, the design is actually very similar to the


approach, although ours will look more like this:

(Struts) ActionServlet --->Action--(RMI)-->SessionFacade--->Hibernate--->DB

In addition, through EJBs, your container can provide some level of automatic transaction demarcation and management.

But scottwilson is correct, EJBs are not without their complications. One of the biggest problems I see is that since our domain objects need to be passed to the client across a remote layer (RMI), they have to be serializable. The lazy-loading proxies hibernate uses (as with any lazy-loading proxy) are not serializable. So in effect, we cannot directly use lazy loading. Instead, we have to either use eager loading (which with the rich relationships in our database could lead to loading huge object graphs to retrieve only a handful of properties), or implement some sort of customizable copying strategy which will copy an object graph at a specified depth. As far as this is concerned, I don't yet have a good plan. I'm hoping Hibernate in Action will give me an idea of how to handle the problem.

Well, I just got my copy of Hibernate in Action and the deep copying problem was briefly discussed as promised. It seems the most appropriate solution for me will be to use a DAO layer (see http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm for a brief description of this) to provide more complete control over what is and isn't loaded.

I know, *groan* -- another layer. But the beauty of this approach is that it lets me leverage lazy loading while still allowing serialization of objects over the RMI layer. And I don't have to create a bunch of Transfer Objects either (referred to in the book as generally a bad idea for a number of reasons, including the fact that it adds a sort of a "fake" reimplementation of the domain model.

I had looked at DAOs before briefly and thought it was just another layer to give me grief, but Christian and Gavin's explanation of how it solves my problem made perfect sense. I guess that makes me a believer, eh?

I still think a wonderful feature of hibernate would be to have additions to the framework that would allow declared access plans for shallow/deep copying of objects. Such objects would be disconnected when retrieved and would have to explicitly be asked for. This could be something like a copyDataGraph() method on the session that took a root object (or collection of root objects?) and a named access plan (presumeably declared in the hbm.xml files) and retrieve a graph of copied objects based on that plan -- i.e.



Of course, a very hard part of this would be figuring out a way of intuitively declaring such an access plan.

Ah, well... I'd like World Peace and an end to starvation too ;)

This one would be very, very nice ... (i think that many developers hardcode this in their business logic)

in some projects i was using a "prototype object tree":
just create an empty object tree (just set the objects) and a util class checks all non-primitive members:
if they are 'NOT null' they are copied ... (for collections just set one object)