Facade Pattern

       In EJB, we recommend to use session facade pattern to let the present layer access the business layer. But in lightweight framework, we use POJO facade instead of session facade. There is no doubt that POJO facade is different from session facade. However, the common characteristic between them is  that both session facade and POJO facade are based on the facade pattern. So today I am going to make a brief introduction to facade pattern according to my own understanding.

       To be honest, compared with the other design patterns, facade pattern is easier to understand in my opinions. The general purpose of using facade pattern is to reduce the complexity of the system. The basic concept of facade pattern is to provide a simple interface to a complex subsystem, and the clients of the subsystem must access it through this interface, thereby promoting subsystem independence and portability.

       People prefer to taking the car as an example to explain the facade pattern. If we compare the car to the system, the driver will be the client of the system and the steering wheel will be the facade interface. In order to drive the car, the driver just need to interact with the sterring wheel. He doesn’t need to knwo how the engine works and how the tires turn.

//the subsystem 
public class Engine{
     public void works(){…}
}

public class Tire{
      public void turn(){…}
}

//the interface
public class SterringWheel{
       private Engine engine;
       private Tire tire;
      //setter injection
      public void set(Engine engine){
           this.engine = engine;
       }
      public void set(Tire tire){
           this.tire = tire;
      }

      //encapsulate the detail of the subsystem
      public void driven(){
            engine.works();
            tire.turn(); 
      }
}

//the client
public class Driver{
     private SterringWheel sterringWheel;
     public void setSterringWheel(SterringWheel sterringWheel)
     {
              this.sterringWheel = sterringWheel;
     }
    public void drive(){
              SterringWheel.driven();
    }
}

Five J2EE design decisions!

        Several days ago, I finished reading the book-POJO in Action. I really benefit a lot from this book, therefore, in the next few days, I would like to write some conclusions about this book combined with my own thought.
        In the chapter 2 of this book, the author lists 5 design decisions we need to make when we design the business logic layer of a system. The five decisions are:

• How to organize the business logic?
• How to encapsulate the business logic?
• How to access the database?
• How to handle concurrency in short transactions?
• How to handle concurrency in long-running transactions?

      Next, I am going to explain the five questions one by one?
      How to organize the business logic? Martin Fowler thinks that there are three patterns to organize the business logic, Transaction Script, Domain Model and Table Module respectively. The concept of Transaction script is procedure-oriented programming, so it is suitable for simple applications. The concept of both Domain Model and Table Module is object-oriented programming. The differences between them is that Table module maps a class to a table, and Domain Model maps a class to one row of a table. The common experience is that it is hard to maintain the application realized by Table Module. So Domain Model is usually our first choice to organize the business logic.

      How to encapsulate the business logic? In a layer architecture, we need to make each layer independent to its neighbor by encapsulating each layer to hidden the detail. Usually, we think that the best practice to do that is using facade pattern. However, sometimes, because of the problem of open session in view, we cannot apply the facade pattern everywhere, instead, we have to choose Exposed Domain Model pattern, which let the present layer access the business model directly instead of the facade interface. It is obvious that both facade pattern and exposed domain model have advantages and disadvantages, and choosing which one depends on the the requirement of the applications.

      How to access the database? Currently, there are several ways to access the database, for example, using JDBC to access the database directly, using iBATIS and uing ORM framework. Just as I said in a former article – find balances between technologies, there is no rule to direct us to adopt one and abandon the others. By the way, according to the popularity of the ORM framework, most people select it as their first choice. However, please remember it is not absolute.

      How to handle concurrency in short transactions? Usually, we call short transactions database transactions, and long-running transactions application transactions. According to the author of the book of POJO in Action, we can use optimistic locking or pessmistic locking to handle concurrency. Optimistic locking derives its name from the fact it assumes that concurrent updates are rare and the application detects and recovers from concurrency instead of preventing them. However, the pessmistic locking assumes that concurrent updates will occur and must be prevented.

      How to handle concurrency in long-running transactions?  The author also lists two methods to deal with this problem, optismistic offline locking and pessmistic offline locking. The differences between them are the same as the ones between optismistic locking and pessmistic locking.

      I hope the information above can give you a little bit help. By the way, The design of business logic is a very complicated question. Sometimes, even though you have a good knowledge of the concept of designing, you still cannot make a good work, because experience plays an important role in the process of desinging.