<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    kapok

    垃圾桶,嘿嘿,我藏的這么深你們還能找到啊,真牛!

      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
      455 隨筆 :: 0 文章 :: 76 評論 :: 0 Trackbacks

    轉自:Karl Baum's Weblog

    Karl Baum's Weblog

    All | General | Java

    
20040708
Thursday July 08, 2004

    Lazy Initialization and the DAO pattern with Hibernate and Spring

    Hibernate and Lazy Initialization

    Hibernate object relational mapping offers both lazy and non-lazy modes of object initialization. Non-lazy initialization retrieves an object and all of its related objects at load time. This can result in hundreds if not thousands of select statements when retrieving one entity. The problem is compounded when bi-directional relationships are used, often causing entire databases to be loaded during the initial request. Of course one could tediously examine each object relationship and manually remove those most costly, but in the end, we may be losing the ease of use benefit sought in using the ORM tool.

    The obvious solution is to employ the lazy loading mechanism provided by hibernate. This initialization strategy only loads an object's one-to-many and many-to-many relationships when these fields are accessed. The scenario is practically transparent to the developer and a minimum amount of database requests are made, resulting in major performance gains. One drawback to this technique is that lazy loading requires the Hibernate session to remain open while the data object is in use. This causes a major problem when trying to abstract the persistence layer via the Data Access Object pattern. In order to fully abstract the persistence mechanism, all database logic, including opening and closing sessions, must not be performed in the application layer. Most often, this logic is concealed behind the DAO implementation classes which implement interface stubs. The quick and dirty solution is to forget the DAO pattern and include database connection logic in the application layer. This works for small applications but in large systems this can prove to be a major design flaw, hindering application extensibility.

    Being Lazy in the Web Layer

    Fortunately for us, the Spring Framework has developed an out of box web solution for using the DAO pattern in combination with Hibernate lazy loading. For anyone not familiar with using the Spring Framework in combination with Hibernate, I will not go into the details here, but I encourage you to read Hibernate Data Access with the Spring Framework. In the case of a web application, Spring comes with both the OpenSessionInViewFilter and the OpenSessionInViewInterceptor. One can use either one interchangeably as both serve the same function. The only difference between the two is the interceptor runs within the Spring container and is configured within the web application context while the Filter runs in front of Spring and is configured within the web.xml. Regardless of which one is used, they both open the hibernate session during the request binding this session to the current thread. Once bound to the thread, the open hibernate session can transparently be used within the DAO implementation classes. The session will remain open for the view allowing lazy access the database value objects. Once the view logic is complete, the hibernate session is closed either in the Filter doFilter method or the Interceptor postHandle method. Below is an example of the configuration of each component:

    Interceptor Configuration

    <beans> 
      <bean id="urlMapping"     
         class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">    
           <property name="interceptors">
             <list>
                  <ref bean="openSessionInViewInterceptor"/>
             </list>
           </property>
           <property name="mappings">
      ...
      </bean>
      ...
      <bean name="openSessionInViewInterceptor"  
        class="org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor">
           <property name="sessionFactory"><ref bean="sessionFactory"/></property>
      </bean>
    </beans>

    Filter Configuration

    <web-app>
     ...      
      <filter>
        <filter-name>hibernateFilter</filter-name>
        <filter-class>
          org.springframework.orm.hibernate.support.OpenSessionInViewFilter
        </filter-class>
       </filter>
      ...      
      <filter-mapping>
        <filter-name>hibernateFilter</filter-name>
         <url-pattern>*.spring</url-pattern>
      </filter-mapping>
      ...
    </web-app>

    Implementing the Hibernate DAO's to use the open session is simple. In fact, if you are already using the Spring Framework to implement your Hibernate DAO's, most likely you will not have to change a thing. The DAO's must access Hibernate through the convenient HibernateTemplate utility, which makes database access a piece of cake. Below is an example DAO.

    Example DAO

    public class HibernateProductDAO extends HibernateDaoSupport implements ProductDAO  {      
    
           public Product getProduct(Integer productId) {
                  return (Product)getHibernateTemplate().load(Product.class, productId);
           }
    
           public Integer saveProduct(Product product) {
                  return (Integer) getHibernateTemplate().save(product);
           }       
    
           public void updateProduct(Product product) {
                  getHibernateTemplate().update(product);
           }
     }

    Being Lazy in the Business Layer

    Even outside the view, the Spring Framework makes it easy to use lazy load initialization, through the AOP interceptor HibernateInterceptor. The hibernate interceptor transparently intercepts calls to any business object configured in the Spring application context, opening a hibernate session before the call, and closing the session afterward. Let's run through a quick example. Suppose we have an interface BusinessObject:

    public interface BusinessObject { 
         public void doSomethingThatInvolvesDaos(); 
    }

    The class BusinessObjectImpl implements BusinessObject:

    public class BusinessObjectImpl implements BusinessObject {
        public void doSomethingThatInvolvesDaos() {
            // lots of logic that calls
            // DAO classes Which access 
            // data objects lazily
        }
    }

    Through some configurations in the Spring application context, we can instruct the HibernateInterceptor to intercept calls to the BusinessObjectImpl allowing it's methods to lazily access data objects. Take a look at the fragment below:

    <beans>
        <bean id="hibernateInterceptor" class="org.springframework.orm.hibernate.HibernateInterceptor">
             <property name="sessionFactory">
               <ref bean="sessionFactory"/>
             </property>
        </bean>
        <bean id="businessObjectTarget" class="com.acompany.BusinessObjectImpl">
           <property name="someDAO"><ref bean="someDAO"/></property>
        </bean>
        <bean id="businessObject" class="org.springframework.aop.framework.ProxyFactoryBean">
             <property name="target"><ref bean="businessObjectTarget"/></property>
             <property name="proxyInterfaces">
               <value>com.acompany.BusinessObject</value>
             </property>
             <property name="interceptorNames">
               <list>
                  <value>hibernateInterceptor</value>
               </list>
             </property>
         </bean>            
    </beans>
    

    When the businessObject bean is referenced, the HibernateInterceptor opens a hibernate session and passes the call onto the BusinessObjectImpl. When the BusinessObjectImpl has finished executing, the HibernateInterceptor transparently closes the session. The application code has no knowledge of any persistence logic, yet it is still able to lazily access data objects.

    Being Lazy in your Unit Tests

    Last but not least, we'll need the ability to test our lazy application from J-Unit. This is easily done by overriding the setUp and tearDown methods of the TestCase class. I prefer to keep this code in a convenient abstract TestCase class for all of my tests to extend.

    public abstract class MyLazyTestCase extends TestCase {
    
            private SessionFactory sessionFactory;
            private Session session;
    	
            public void setUp() throws Exception {
    	    super.setUp();
    	    SessionFactory sessionFactory = (SessionFactory) getBean("sessionFactory");
    	    session = SessionFactoryUtils.getSession(sessionFactory, true);
    	    Session s = sessionFactory.openSession();
    	    TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(s));
    
            }
    
            protected Object getBean(String beanName) {
                //Code to get objects from Spring application context
            }
    	
            public void tearDown() throws Exception {
    	    super.tearDown();
    	    SessionHolder holder = (SessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
    	    Session s = holder.getSession(); 
    	    s.flush();
    	    TransactionSynchronizationManager.unbindResource(sessionFactory);
    	    SessionFactoryUtils.closeSessionIfNecessary(s, sessionFactory);
            }
    }
    
    ( Jul 08 2004, 09:39:55 AM EDT ) Permalink Comments [2]

    Trackback URL: http://jroller.com/trackback/kbaum/Weblog/orm_lazy_initialization_with_dao
    Comments:

    A few things to keep in the back of your mind if you take this approach; 1. If any errors occur while attempting to lazy load relationships in the view (JSP) it would be hard to present a nice error to the user. 2. This would result in at least 2 hibernate sessions (db connections being open for any one request), so you might want to up the number of connections available. Cheers, Dan

    Posted by Dan Washusen on July 08, 2004 at 09:02 PM EDT #

    I am a little confused on why it would be difficult to show a nice error jsp. Couldn't we just use the provided servlet container error page mechanisms? In regards to the 2 hibernate sessions being opened. Are you saying that the OpenSessionInViewInterceptor would be run twice if an exception was thrown? Thanks for your feedback!

    Posted by Karl Baum (63.170.158.133) on July 09, 2004 at 09:48 AM EDT #

    posted on 2005-05-24 00:07 笨笨 閱讀(692) 評論(0)  編輯  收藏 所屬分類: J2EEHibernateAndSpringALL
    主站蜘蛛池模板: 亚洲免费在线视频| 美女被免费网站在线视频免费| 麻豆成人久久精品二区三区免费 | 免费A级毛片无码免费视| 亚洲精品无码mv在线观看网站| 91精品国产免费久久国语蜜臀| 亚洲精品影院久久久久久| 亚洲国产精品成人AV无码久久综合影院 | 亚洲精品无码成人AAA片| 无码人妻久久一区二区三区免费丨 | 亚洲第一精品在线视频| www国产亚洲精品久久久日本| 88xx成人永久免费观看| 亚洲av无码一区二区三区网站 | 少妇性饥渴无码A区免费| 免费无码国产V片在线观看| 亚洲国产av美女网站| 国产免费人视频在线观看免费 | 99久久成人国产精品免费 | 亚洲一本到无码av中文字幕 | 亚洲成AV人片在线观看无码| 中文字幕第一页亚洲| 亚洲色图黄色小说| 国内精品免费在线观看| 亚洲成AV人片在线观看无| 中文字幕免费观看| 亚洲国产精品成人午夜在线观看| 日本无卡码免费一区二区三区| 一级黄色免费网站| 久久亚洲精品成人| 成人免费无码大片A毛片抽搐 | 美女裸体无遮挡免费视频网站| 国产午夜亚洲精品午夜鲁丝片| 久久久久免费看成人影片| 亚洲午夜福利在线视频| 亚洲自偷自偷偷色无码中文| 中文字幕亚洲免费无线观看日本| 亚洲爆乳大丰满无码专区| 亚洲精品无码成人AAA片| 国产精品成人免费一区二区 | 国产JIZZ中国JIZZ免费看|