2010-10-26 2 views
8

Вот сценарий,как отвязать данные из бизнес-логики

Допустим, у меня есть пользовательский класс следующим образом:

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

Тогда у меня есть класс, как можно так обращаться с пользователем Комментарии:

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

Пока что очень простой материал. Однако я хочу добавить некоторых помощников, чтобы облегчить загрузку комментариев для пользователя. Поэтому я мог бы создать что-то в классе User:

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

Я думаю, что это простой способ не проходить вокруг пользовательских экземпляров. Но на данный момент я несчастлив, потому что я связал свой пользовательский объект bean с бизнес-логикой, которая загружает комментарий. Я также сохранил счетчик по умолчанию в классе пользователя, который не должен быть там. Итак, каков наилучший способ сделать это? Моя цель - передать этот объект в jsp, чтобы функции JSTL могли быть вызваны. У меня возникла идея создать UserWrapper, который будет выглядеть так ...

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);} 
} 

Надеюсь, я был чист. Мне не нравится использовать тег useBean, потому что его просто не нужно для чего-то подобного. Я надеюсь, что есть более чистый способ приблизиться к чему-то подобному! Любая помощь будет оценена!

Редактировать: Одна вещь, о которой я забыл упомянуть. Я хочу использовать этот код в JSTL. Это означает, что это должен быть геттер. Модель DAO хорошо известна, но это не слишком помогает, когда моему разработчику переднего плана необходимо написать скрипт, или мне нужно загрузить его для тех мест, которые он может или не понадобится.

+0

Хммм, подумав об этом. Я думаю, что лучше задать вопрос, что обычно DAO - это все статические функции. Что произойдет, если вам нужно передать один параметр для каждой функции. Скажем, токен oAuth. Я думаю, что в этом случае было бы разумно не делать только статичное DAO и заставить его принимать токен в качестве конструктора. Как новый UseDao (String token); Есть предположения? –

+0

hmmmm, который отвечает, чтобы принять: P –

ответ

3

С технологической независимой стенд точки ...

Да, вы абсолютно правы, что сцепка быть непомерно высокой. Посмотрите на Layers architectural pattern, чтобы предложить некоторые рекомендации по структуре бизнес-логики и данных. Например, может быть отличной идеей разработать две подсистемы: один для вашей логики, другой для слоев. Ограничьте связь между ними только , позволяя логике передавать сообщения на уровень данных. Кроме того, вы можете использовать Facade pattern для представления каждой подсистемы и, таким образом, уменьшить сцепление еще больше. Обработайте каждый слой как черный ящик.

Другой шаблон, который может пригодиться, - Data Access Object pattern. Это поможет вам определить контракт между слоями для передачи данных по мере необходимости.

+0

Несколько раз, имея DAO, это просто избыток. Предположим, у меня есть комментарии, уведомления, электронные письма, обновления статуса и т. Д. ... Создание огромного файла просто загружает эти данные не так чисто.Плюс я не мог назвать это прямо из jsp. Я забыл упомянуть, одна цель - написать меньше кода! ха-ха. Я могу создавать фасады, DAO и просто найти огромный кошмар для управления. –

+2

Попробуйте инкрементное развитие. Планируйте это на бумаге и посмотрите, все ли проверено (попросите друга убедиться, что ваш дизайн нормальный). И ты абсолютно прав. Идеальный дизайн лучше. Но убедитесь, что он делает все, что вы хотите, и что он слабо связан. Легко, правда? :) – Mike

+0

+1 Майк. @Amir - дело в архитектуре - иметь представление о том, где вы хотите/нужно пойти с приложением; это сильно отличается от YAGNI. Я обнаружил, что (как правило), как только вы примете подход, похожий на Майка, вы быстро познакомитесь с ним, и проблема «управления» эффективно исчезает. –

2

Мне нравится использовать объекты доступа к данным (DAO) для этого. Классы User и Comment будут содержать только поля для этих объектов, а затем вы создадите отдельные классы для извлечения данных об этих объектах. DAO, где вы включаете логику о том, как извлекать, обновлять, выбирать и т. Д. Например,

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 
    } 
Смежные вопросы