Java / Spring: Бобы для Представления - PullRequest
3 голосов
/ 22 октября 2010

У меня есть дилемма, и я не уверен в том, как лучше ее решить.

Я работаю со старой базой кода на работе.Некоторые из доменных объектов (и таблиц БД за ними) не имеют большого смысла.например, deleted хранится как long, age хранится как String и т. д. С которым я смог нормально работать.По мнению могу сказать if (deleted == 1)....Но есть некоторая специфическая бизнес-логика, которая ведет к проблеме обслуживания, если она у вас на виду.Вот один пример:

String title = null;
if (obj.getTitle != null) {
    title = obj.getTitle();
} else {
    title = obj.getName() + " - " + obj.getCategory();
}

Мне бы очень хотелось иметь «компонент представления», где эта бизнес-логика и законные странности сглаживаются и сохраняются, чтобы я мог использовать ее в нескольких представлениях, но затем изменить водно место.Если бы у меня был Product POJO, а затем мой ProductViewBean, например, я бы сделал что-то вроде:

productViewBean.setDeleted( product.getDeleted() == 1 );
productViewBean.setTitle( product.getTitle() != null ? product.getTitle() : product.getName() + " - " + product.getCategory() );

Мой вопрос: где мне это делать?Должен ли я иметь manager (с соответствующим daos, введенным в него), который вводится в мой controller и возвращает мой «компонент просмотра»?Или я все об этом говорю неправильно, и может ли быть лучший подход?

Заранее спасибо

(Примечание: я понимаю, что основная структура - это реальная проблема, но она находится за пределами моей юрисдикцииизменить на этом этапе. Слишком много проектов используют эти доменные объекты. И даже если я действительно очистил объекты db / domain (чтобы deleted был boolean и т. д.), я все еще остался с неизбежной бизнес-логикой (если!title, затем «построить заголовок из других компонентов»), который не принадлежит слою данных и который я хотел бы инкапсулировать в одном месте, чтобы ни контроллер, ни представление не беспокоились об этом, и его можно использовать на нескольких контроллерах /Я попал в точку, где я могу написать что-то эффективное и поддерживаемое, и даже может создать хороший слой для облегчения очистки этих доменных объектов в будущем.)

Ответы [ 2 ]

1 голос
/ 22 октября 2010

Готов поспорить, что вы можете разобраться со всем этим в API привязки и проверки данных Spring.

Я бы также сказал, что у вас должен быть уровень обслуживания, отличный от уровня веб-контроллера. Добавьте сервисы на веб-уровень и позвольте им выполнять всю работу. Они беспокоятся о единицах работы, транзакциях и объектах DAO.

0 голосов
/ 22 октября 2010

Я бы попробовал делегирование Адаптера объекту домена, как показано ниже. Контроллер и просмотр используют этот. Если ProductViewBean находится в том же пакете, что и менеджер, менеджер может использовать только метод getDelegate() для передачи его в dao.

public class ProductViewBean {
  private final Product delegate;

  public ProductViewBean(Product delegate) {
    this.delegate = delegate;
  }

  Product getDelegate() {
    return delegate;
  }

  public String getTitle() {
    if (delegate.getTitle == null) {
      return delegate.getName() + " - " + delegate.getCategory();
    }
    return delegate.getTitle();
  }

  public void setTitle(String title) {
    delegate.setTitle(title);
  }

  public boolean isDeleted() {
    return delegate.getDeleted() == 1L;
  }

  public void setDeleted(boolean deleted) {
    delegate.setDeleted(deleted ? 1L : 0L);
  }

  ...
}

Так что вы можете сделать API, который вам нравится.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...