Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.acegisecurity.domain.dao
Interface InitializationCapable

All Known Implementing Classes:
  DaoHibernate

    public interface InitializationCapable

Indicates an implementation capable of initializing an object, such that any lazy loading is guaranteed to have been completed.

Structured as a separate interface (rather than a subclass of `Dao`), as it is not required for all persistence strategies.

In general the recommended approach to lazy initialization is as follows:

- Do not use OpenSessionInView. You can use it if you like, but you'll have less difficulty in the long-run if you plan your use cases and adopt the other recommendations below.
- Set your mapping documents to use lazy initialization where possible. Only mark an association as eager loaded if every single use case requires it and you are happy with this eager loading being reflected in a mapping document instead of Java code.
- Subclass the `Dao` implementation and add use case specific finder/read methods that will use the persistence engine's eager loading capabilities. Generally this approach will deliver the best overall application performance, as you will (i) only be eager loading if and when required and (ii) you are directly using the persistence engine capabilities to do so. It also places the eager loading management in the `Dao`, which is an ideal location to standardise it.
- If you would prefer to achieve persistence engine independence and/or reduce the number of `Dao` subclasses that exist in your application, you may prefer to modify your services layer so that it uses the `InitializationCapable` interface. However, this interface should be used judiciously given that it does not allow the persistence engine to optimise eager loading for given use cases and (probably) will lead to a mixture of places where fetching logic can be obtained.

Generally your best strategy is subclassing the `Dao`. It means the most code, but it's also by far the most efficient and offers flexibility to further fine-tune specific use cases. Whichever way you go, try to be consistent throughout your application (this will ease your future migration and troubleshooting needs).

Version:
  $Id: InitializationCapable.java,v 1.4 2005/11/17 00:55:47 benalex Exp $
Author:
  Ben Alex

Method Summary
`void` | `initialize(Object entity)` Initializes the indicated object.
`boolean` | `isInitialized(Object entity)` Indicaets whether the passed object is initialized or not.

Method Detail

### initialize

    void initialize(Object entity)

  Initializes the indicated object.

  May throw an exception if the implementation so desires.

  Parameters:
    `entity` - to initialize

### isInitialized

    boolean isInitialized(Object entity)

  Indicaets whether the passed object is initialized or not.

  Parameters:
    `entity` - to determine if initialized
  Returns:
    `true` if initialized, `false` is uninitialized or the initialization status is unknown

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2004-2005 Acegi Technology Pty Limited. All Rights Reserved.