Where do I write business Logic?

Question

Hi,
Where do I write bisiness Logic?
Tutorial said "It is common practice to include the bean property and the Action
implementation to which it refers within the same bean class".
But I thought EventHander Impl is better to write business Logic
like retrieving the data from database.
Which is common use?
Or I need to choose them depending on the situation?
Thanks in advance for you help.
tomo

Answer 1

Thanks for the reply!!
But I am still confused.
I thought I can write business logic A and B.
What is difference between A and B ??
Hi tomo,
In the two options you provide the difference is not that much. The ActionListener instance willhave to be registered in your JSP of course to listen to the button or hyperlink with the f:action_listner tag. But in both cases your biz logic is in your ui. I think that is the wrong direction for you to head.
I think the real question should be (forgive me if I'm pulling the discussion away from your question, but I think this is relevant) where does the business logic go.
As Kito said your biz logic belongs apart from your UI logic (classic MVC approach). So in the real world what does that mean? As you suggest in option B in your last post a bean provides an action so that it can be specified via the actionRef attribute. This action in turn invokes a method on the bean it comes from which then invokes the business logic on the 'real' business logic.
The Action becomes simply a translator (or part of the Adaptor pattern from the GoF book).
For example lets say you have a bean that does biz processing like this;
public interface CatalogFacade {
  public Collection getProducts(ProductSearchCriteria criteria);
}And you want to invoke that 'business logic' from your JSF UI. The button would be declared with this code
<h:comman_button id="searchCommand" type="submit"
                    label="Search"
                    commandName="search"
                    actionRef="searchBean.searchAction"/>In your searchBean you have many options to return the searchAction but I prefer the following
public class SearchBean {
   public SearchFacade searchFacade = null; // this could be a managed bean or an EJBSession or whatnot
   public ProductSearchCriteria productSearchCriteria = null; // this should be 'filled' in by the form the button is on
   private transient Action searchAction = new Action() {
    public String invoke() {
      return search();
  public Action getSearchAction() {
    return searchAction;
  public void search() {
    Collection products = searchFacade.search(productSearchCriteria);
    // place the products collection into the next page's bean so that is can be found via valueRef attributes
}Notice that no database hits are happening in the UI code. Also there is no business logic here either.
It is very important to keep these two concerns divided for ease of maintenance. The typical reasoning goes something like this, 'your ui is very likely to change so keep it separate from your business logic'. Other reasons to be careful about mixing UI and biz logic is the likely hood that you will get very different behavior (one probably wrong) if you have to and another client to your biz logic.
For example in the earlier product search stuff. If we needed a web service front end to the 'searchProducts' functionality and we had the db hit happening in the action or page bean we would be stuck. With the above impl we get to just put a WS over the facade and we are done.
Hope this helps.
You can also look at some of the blueprint patterns for more info. They start here;
http://java.sun.com/blueprints/patterns/index.html
While some of the EJB specific patterns might be more involved than you need they provide excelent archtectural guidence for web only apps as well.
Good luck,
-bd-