2010-10-26 9 views
8

Aquí está el panorama,como desacoplar los datos de la lógica de negocio

Digamos que tengo una clase de usuario, así:

public class User{ 
    private String firstName; 
    private String lastName; 
//... 
// setter, getters 
} 

Entonces tengo una clase al igual que para manejar usuarios Comentarios:

public class Comments{ 
    // some fields 
    public static loadComments(User user, int count){...} 
} 

Hasta ahora, cosas muy básicas. Sin embargo, quiero agregar algunos ayudantes, por supuesto, para que sea más fácil cargar comentarios para el usuario. Así que podría crear algo de la clase Usuario:

final static int defaultCount = 10; 
... 
public Comment comments(){ 
    return Comments.loadComments(this, defaultCount); 
} 

Creo que esta es una manera fácil de no tener que pasar alrededor de las instancias de usuario alrededor. Pero en este momento, no estoy contento porque he acoplado mi objeto bean de usuario con la lógica de negocios que carga el comentario. También guardé el recuento predeterminado en la clase de usuario, que no debería pertenecer allí. Entonces, ¿cuál es la mejor manera de hacer esto? Mi objetivo es pasar este objeto a un jsp para poder llamar a las funciones JSTL. Tuve la idea de crear un UserWrapper que se vería así ...

public class UserWrapper{ 
    private final static defaultCount = 10; 
    private final User user; 
    public UserWrapper(User user){ 
    this.user = user; 
    } 

    // should probably cache this but i am not going to show this for simplicity 
    public Comments getComments(){return Comments.loadComments(user, 10);} 
} 

Espero haber sido claro. No me gusta usar la etiqueta useBean porque simplemente no es necesario para algo como esto. ¡Espero que haya una forma más limpia de abordar algo como esto! ¡Cualquier ayuda sería apreciada!

Editar: Una cosa que olvidé mencionar. Quiero poder usar este código en JSTL. Lo que significa que debe ser un getter. El modelo DAO es bien conocido pero no ayuda demasiado cuando mi desarrollador front-end necesita escribir un scriplet o necesito cargarlo para lugares que puede o no necesitar.

+0

Hmmm después de pensarlo. Creo que una mejor pregunta que hacer es que, por lo general, los DAO son todas funciones estáticas. ¿Qué sucede si tiene que pasar un parámetro a cada función? Digamos una ficha de OAuth. Creo que en ese caso, tendría sentido no hacer el DAO estático solamente y hacer que acepte un token como el constructor. Como nuevo UseDao (String token); ¿Alguna idea? –

+0

hmmmm que responden aceptar: P –

Respuesta

3

Desde un punto de la tecnología de stand-independiente ...

Sí, tienes toda la razón en que el acoplamiento de ser prohibitivo. Consulte el Layers architectural pattern para ofrecer alguna orientación sobre la estructura, lógica de negocio y datos. Por ejemplo, podría ser una excelente idea diseñar dos subsistemas: uno para su lógica y el otro para las capas. Restrinja la comunicación entre ellos por solo permitiendo que la lógica pase mensajes a la capa de datos. Además, puede usar el Facade pattern para representar cada subsistema, y ​​así disminuir el acoplamiento aún más. Trata cada capa como una caja negra.

Otro patrón que puede ser útil es el Data Access Object pattern. Le ayudará a definir un contrato entre las capas para pasar datos cuando sea necesario.

+0

Algunas veces tener un DAO es solo una exageración. Digamos que tuve comentarios, notificaciones, correos electrónicos, actualizaciones de estado, etc. Crear un archivo enorme solo cargue estos datos no es tan limpio.Además, no pude llamarlo directamente desde jsp. Olvidé mencionar, ¡un objetivo es escribir menos código! jaja. Puedo crear fachadas, DAO, y solo para encontrar una gran pesadilla para gestionar. –

+2

Pruebe el desarrollo incremental a continuación. Planifíquelo bien en papel y vea si todo sale bien (consiga un amigo para asegurarse de que su diseño esté en forma). Y tienes toda la razón. Un diseño delgado es lo mejor. Pero asegúrate de que haga todo lo que desees, y que esté ligeramente acoplado. Fácil, ¿verdad? :) – Mike

+0

+1 Mike. @Amir: lo importante de la arquitectura es tener una idea de dónde quieres/necesitas acceder con la aplicación; esto es muy diferente de YAGNI. Descubrí que (generalmente) una vez que adoptas un enfoque como el de Mikes, te familiarizas rápidamente con él y el problema de "administración" desaparece de manera efectiva. –

2

Me gusta usar objetos de acceso a datos (DAO) para esto. Sus clases User y Comment solo contendrán los campos para esos objetos y luego creará clases separadas para recuperar datos sobre esos objetos. Los DAO son donde incluye la lógica sobre cómo recuperar, actualizar, seleccionar, etc. Por ejemplo,

public class UserDAO { 

    public UserDAO() { 
     //maybe setup a Hibernate connection or JDBC connection here 
    } 

    public User getUser(int userId) { 
     User user; 
     //code to retrieve user from datasource 
     return user; 
    } 

    //other methods for update, delete, select, etc 
    } 

    public class CommentsDAO { 
    private static int DEFAULT_COUNT = 10; 

    public CommentsDAO() { 
     //maybe setup a Hibernate connection or JDBC connection here 
    } 

    public Collection getCommmentsForUserWithCount(User user, int count) { 
     Collection comments = new Set(); 
     //retrieve comments from datasource limit to count 

     return comments; 
    } 

    public Collection getCommentsForUser(User user) { 
     return getCommentsForUserWithCount(user, DEFAULT_COUNT); 
    } 

    //other methods for update, delete, etc 
    } 
Cuestiones relacionadas