Five ‘s Weblog

October 25, 2007

Exposed Domain Model Pattern

Filed under: Five's thought — by powerdream5 @ 11:10 pm
Tags: , , , ,

       In my former articles, I have mentioned “open session in view” many times. What is open session in view? When we use Hibernate framework, the Hibernate session will be closed after a transaction being submitted. Then, when the presenter layer of a web application accesses the detached objects, it may access an unloaded object because of the mechanism of lazy loading. Therefore, an exception would thrown.

10_25_1_2007.jpg

       One of the good way to handle this problem is using Exposed Domain Model Pattern instead of POJO Facade Pattern. We also call Exposed Domain Model pattern as Open Session in View Pattern. It means the presenter layer can access the business logic layer directly instead of through a facade class.  It is obvious that the advantages of POJO Facade pattern are the disadvantages of Exposed Domain Model. However, If you want to avert the complexity of writting the detached objects, in fact, which are also weak,  Exposed Domain Model pattern is still a good choice.

       In POJO Facade, the facade class need to take care of managing transaction and database connection. In Exposed Domain Model, we have to distribute the two functions to the other parts of the system. Because we have to keep the Hibernate session availabe until the presenter layer finishes rendering the page, the servlet filter is a good place to open and close a session. Spring framework provides such a filter named “OpenSessionInViewFilter” to help us realize this.  Furthermore, we can also start and submit a transaction in the servlet filter. However, it is too complicate to write code to restart a transaction in the servlet filter. Usually, we let the classes in the business layer (for example, the service classes in the domain model) to deal with the transaction.

The following is an example of web.xml file to show how to config spring framework in web.xml:

<web-app>
         /*the listener watches over the creation of ServletContext which store the spring applicationContext*/
        <listener>
             <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
        </listener>
 
        <context-param>/*list the spring configuration files*/
             <param-name>contextConfigLocation</param-name>
             <param-value>/WEB-INF/applicationContext.xml</param-value>
        </context-param>

        <filter>
               <filter-name>OpenSessionInViewFilter</filter-name>
               <filter-class>org.springframework.orm.hibernate.support.OpenSessionInViewFilter</filter-class>
               <init-param>
                        <param-name>sessionFactoryBeanName</param-name>
                        <param-value>sessionFactory</param-value>
              <init-param>
       </filter>

       <filter-mapping>
               <filter-name>OpenSessionInViewFilter</filter-name>
               <url-pattern>/*</url-pattern>
       </filter-mapping>

       ……..
</web-app>

10_25_2_2007.jpg

October 23, 2007

POJO Facade

Filed under: Five's thought — by powerdream5 @ 9:23 pm
Tags: , ,

      The day before yesterday, I made a brief introduction to the Facade pattern. Today, let’s make a little bit advance. Because I am studying lightweight frameworks now, I am pretty willing to share my own knowledge about POJO facade pattern with you!

10_23_1_2007.jpg

      From the name of POJO facade, it is easy to tell that it is based on the facade pattern. The main responsibility of POJO facade is to manage the transaction and database connection. In fact, when we refer to POJO facade, we always like to compare it with Session facade. They have two big differences. The first one is POJO facade donesn’t need the services provided by the EJB Server. Because POJO facade pattern is specific for lightweight framework, such as Spring and Acegi Security, which will provide services to it instead of EJB Server. The second difference is that POJO facade choose to return the domain object to the present layer instead of DTO(Data Transfer object). As we all know, DTO just holds data and not has behaviros. The biggest disadvantage of DTO is that we always need to write a lot repeated and redundant codes to create it.

10_23_2_2007.jpg

      As mentioned above, POJO facade returns domain objects to the present layer instead of DTO. However, this way has one drawback that the present layer may call the mehtods of the domain objects directly instead of through POJO facade, so that these calls will not be executed in transaction. In order to solve this problem, we can combine POJO facade with Adapter pattern. Firstly, we define an interface, which contains all the methods the present layer need access. Then, we should create an adapter which implements this interface. And this adapter will transfer all the requests from the client to the domain objects.

     When we use POJO facade, another problem we need to concern is that how the POJO facade returns the domain objects to the present layer(we call it detach). Because of the problem of open session in view. We have to make sure the domain objects returned by POJO facade are the ones needed by the present layer, and the present layer will not access the other domain objects which have not beed loaded from the database.

10_23_3_2007.jpg

Create a free website or blog at WordPress.com.