2012-09-24 18 views
5

Actualmente estoy utilizando struts2 Framework para el proyecto de mi trabajo, y al diseñar mis clases DAO tengo una pregunta en mente para mejorar los patrones de diseño.Java EE DAO/DTO (Objeto de transferencia de datos) Patrones de diseño

En mi función de búsqueda, que tienen 3 tipos de búsqueda

  1. búsqueda con un parámetro, y el otro,
  2. búsqueda con múltiples parámetros,
  3. búsqueda sin parámetros.

Mi pregunta es, ¿cuál es la mejor manera de hacer el método DAO?

en mi método struts2, estoy teniendo

public String execute() { 

    //assuming these are passed in from JSP 
    if ("searchByAnId".equals(paramSearch)) 
    { 
     List<DTO> datalist = this.someDao.implementList(theIdParam); 

    } else if("searchByAnOtherParam".equals(paramSearch)) 
    { 
     List<DTO> datalist = this.someDao.implementAnotherList(param1, param2, param3, param4) 
     // more params 
    } else 
    { 
     List<DTO> datalist = this.someDao.implementListAll(); 
    }  

    return "success"; 
} 

que estaba leyendo en los patrones de diseño, tales como los métodos de fábrica, métodos decorador, método de observador, pero no estaba seguro de cuál es las más adecuadas (o cualquier otra cosa sin un complemento de terceros) que se adapte a esto?

+1

En mi proyecto, creé un objeto SearchCriteria que contiene las columnas de la tabla a la que pertenece DAO. A continuación, proporcione los detalles en estos objetos de SearchCriteria y realice la búsqueda basada en él dentro de su DAO. – Atul

+0

Y sí, no creo que haya un patrón de diseño específico para esto. – Atul

Respuesta

6

por lo general tienden a crear una interfaz básica DAO con las definiciones de métodos comunes a todos mis entidades de dominio, como:

// marker interface 
public interface DomainEntity extends Serializable { } 

// common dao methods 
public interface DAO<T extends DomainEntity> { 
    public T findById(Long id); 
    public List<T> findAll(); 
    public T save(T entity); 
    public boolean update(T entity); 
    public boolean delete(T entity); 
} 

Y entonces proporcionar una o más implementaciones basadas en mis requisitos:

// implementation of common dao methods using JPA 
public class JpaDAO<T> implements DAO<T> { 

    private EntityManager em; 

    public JpaDao(EntityManager em) { this.em = em; } 

    // Default implementations using JPA... 
} 

// implementation of common dao methods using JDBC 
public class JdbcDAO<T> implements DAO<T> { 

    private Connection conn; 

    public JdbcDao(Connection conn) { this.conn = conn; } 

    // Default implementations using JDBC 
} 

Ahora, suponiendo que tengo la siguiente clase de persona:

public class Person implements DomainEntity { 
    private Long id; 
    private String firstName; 
    private String lastName; 

    // getters/setters... 
} 

En primer lugar definir una interfaz genérica PersonDao así:

public interface PersonDAO implements DAO<Person> { 
    public List<Person> findByFirstName(String name); 
    public List<Person> findByLastName(String name); 
} 

Tenga en cuenta que en mi interfaz específica entidad DAO anterior, he incluido sólo los métodos adicionales que son específicos a mi entidad del dominio. Los métodos comunes son heredados por la interfaz súper y se parametrizan a mi entidad de dominio usando genéricos.

Ahora lo último que queda es definir diferentes implementaciones de mis métodos específicos de la entidad, así:

package mypackage.daos.jpa; 

public class PersonDAOImpl extends JpaDAO<Person> implements PersonDAO { 
    // here i implement only the entity specific dao methods 
    // defined in the last interface. 
} 

Si también necesito para proporcionar una implementación alternativa DAO (digamos basado en JDBC en lugar de JPA), su tan fácil como crear una segunda clase (de preferencia en un paquete separado):

package mypackage.daos.jdbc; 

public class PersonDAOImpl extends JdbcDAO<Person> implements PersonDAO { 
    // again i only implement the entity specific DAO methods since 
    // defaults have been implemented in the super class... 
} 

lo bueno de esto es que se puede cambiar implementaciones sin el código de llamada se vea afectado por lo siguiente:

// a service class that uses my dao 
public class PersonService { 

    private PersonDAO dao; 

    public PersonService(PersonDAO dao) { this.dao = dao } 

    public void doSomethingUseful() { 
    // use the dao here... 
    } 
} 

Normalmente, la implementación adecuada de dao (jdbc o jpa) se inyectaría a través del constructor durante la creación del servicio. Por supuesto, puede tener solo una implementación si lo desea (es decir, jpa).

+0

Entonces, solo para confirmar, ¿cuál es la relación entre "interfaz PersonDAO" y "DAO "? Disculpas, soy bastante malo en los patrones de diseño ... –

+0

Interfaz DAO es una interfaz de tipo parametrizada que define las operaciones DAO que son comunes a todas las entidades de dominio. La interfaz PersonDAO (que extiende DAO) incluye las operaciones que son específicas de la entidad de dominio Person. –

+0

En cuanto al genérico PersonDao, ¿no debería leer 'la interfaz PersonDao extiende Dao ' en lugar de 'implements'? – Louise