Now I just leading a team to develop a HR system,we want to use Struts + hibernate ,I don't want to put the bussiness logic into the struts' action,I want to add a layter between hibernate and struts, but I don't know how to encuplate the business layer
  and by the way, in our HR system, It has many workflow so, the logic is very complated,I find a book it used business delegate,but the example is so simple,I don't how to design in my project,pls give some advice

I'm sorry to ask you this, man, but someone should have already... How did you get to lead a team if you don't know how to design your app???
Now, to the point.
+1 with NOT putting your business logic in the Struts action. What if tomorrow you need a desktop GUI?
That said, its nearly impossible to give you accurate advice without knowing a lot more about your app. Lot's of business logic in the shape of processes, or just simple plain logic (check-the-user-is-enabled kind of logic)?
Just design following OOD concepts, and THEN consider the technologies you'll use in implementation.
Perhaps you'll find it's correct to put this logic in the same classes that will be persisted with Hibernate, why not?
Maybe you need session EJBs.
Post some more information about the project, perhaps that'll help giving a better advice...

Regards,
Martin

:(,I just begin to develop the project,and now we just begin to do requirement resarch, we neve used hibernate,our company also want us to make some new tech preparations for other project,so ,we has some tech adventers ,then I have to prepare the architecture ahead of schedule ,becaues in our design, table's relationship is quite a lot ,so I cann't do the main logic in bussiness object,because, in one request, it need to visit many business object
    I find many instance online ,they used busness delegate + session facade +dao+hibernate,can I not used session facade ?,just use business delegate + DAO+hibernate?

they used busness delegate + session facade +dao+hibernate,can I not used session facade ?,just use business delegate + DAO+hibernate?

So, you want your business delegate to "connect" directly to the DAO? That's a two-layers architecture. Nothing wrong with it, but it has lots of issues. Three layers is prefferable, I think. You can have a three-layers/one-tier architecture, no problem there. On the other hand, I'm not quite sure the Business Delegate pattern applies to the usage you described.
Why do you say you cant use the business objects? Perhaps
we don't agree on what we call "business objects"...

Regards,
Martin

thank you for your patience to answer my question,but I still have many confusion,

what is a three-layers/one-tier architecture? Can you tell me the detail ?

and wether the business delegate is applied to my project is a problem confused me ,can you tell me which case does business delegate apply to ?

what is a three-layers/one-tier architecture?

Layers represent "logic" divisions of a system. Tiers represent phisical divisions. For instance, in a common client/server application, the client is in one tier and the server in the other. When you divide your system in layers, the architecture allows you to - for instance - modify the business logic without affecting the presentacion or persistence layers. Kind of a black box for each layer.
Three-layers/one-tier means (badly speaking) your application is logicaly divided in three layers, but runs in just on machine.
LOTs of books and papers and articles around the web about this.

Regards,
Martin

thank you very much,I want to add a layer to encapsulate business logic between struts action and DAO ,so when business logic is changed,it have little influencs to presentation,maybe I will used business delegate + session bean,but I still thought of whether it applied to my APP and another alternative way ,may a OOD desgined class can solved ,thank you any way

best wish to you

mary

I've had a similar problem and after a bit of trial and error. I have realized that separation of presentation(struts), logic and persistence(hibernate) is not as easy as you might think.

I am gonna outline one of my designs below, I am open to suggestions on how to improve on this from the ppl who are more experienced than me offcourse.

Don't use descendants of ActionForm as persistence beans.

Keep hibernate-session open atleast until ActionForm-descendants populated. Otherwise you will may polute business layer with descitions about how much data to fetch based on presentation requirements(1.1 & 1.2).
I achieve this by deriving actions that rely on persistent data from a servlet that opens session, begins transactions / commits transactions (my transactions all fit within 1 request)(2).
Avoid putting business logic in persistence beans, such as validating stuff inside setters, this may prevent loading legacy data that doesnt conform to business rules.

1.1 Example causing lazy load exceptions (pseudo)
Inside ListFoosAction:
...
request.setAttribute("fooListForm", new FooListForm(new FooForm(forEach(FooBusiness.getAllFoos())));
...
Inside FooBusiness.getAllFoos():
...
Session session = sessionFactory.openSession();
ret=session.find("from Foo");
session.close();
return ret;
...

1.2 Business Layer traversing object graph to avoid lazy exception:
Inside action:
...
request.setAttribute("fooListForm", new FooListForm(new FooForm(forEach(FooBusiness.getAllFoos())));
...
Inside FooBusiness.getAllFoos():
...
Session session = sessionFactory.openSession();
ret=new LinkedList(session.find("from Foo"));
session.close();
return ret;
...

2.0 ReadAction creates database sessions, descendants passing them on, but otherwise ignores them:
In ReadAction:
...
execute(...){
Session session=sessionFactory.openSession();
execute(Session,...);
session.close();
}
abstract execute(Session,...);
...
In ListFoosAction:
... extends ReadAction {
execute(Session session,...){
   FooBusiness.getAllFoos(session);
}
...
}

You get the idea i hope.

you want your business delegate to "connect" directly to the DAO? That's a two-layers architecture. Nothing wrong with it, but it has lots of issues. Three layers is prefferable, I think.

why it has lots of issues? I find in business delegate + session facade+DAO,business delegate hiding looking up a stateless session bean and encuplate the business method in business delegate implement class again, I cann't understand why need a statless session bean here

and in A app, there are many business method belongs diff module, and every module should have a session faced ?

and every module should have a session faced ?

DAOs belong to the persistence layer. All i'm saying is that you should not connect the presentation layer to the persistence layer if you wish to achieve flexibility, scalability, an all those pretty nouns. Those are the issues I reffered to. Again, I think there's nothing wrong with a 2 layers architecture for a lot of systems. But I also believe you lose nothing by using a 3 layers architecture, with little extra effort. If you DO use 3 layers, you absolutely CAN'T access the DAO from the persistence layer.

Regards,
Martin