Как я могу улучшить этот дизайн, который вызывает сторонние методы из JSF-интерфейса - PullRequest
Новая
       60

Как я могу улучшить этот дизайн, который вызывает сторонние методы из JSF-интерфейса

1 голос
/ 07 сентября 2011

Мне нужны мнения и советы экспертов по дизайну.

Я занимаюсь разработкой приложения с использованием JSF2 и EJB3, и я не с использованием CDI.

Мне далиAPI (jar) от другой команды, и в нем есть три основных метода.Один выполняет поиск в базе данных и возвращает список автомобилей, а другой возвращает список push-байков и один возвращает список лодок.
Таким образом, в основном у нас есть три разных списка разных транспортных средств.

На стороне пользователя пользовательский интерфейс имеетформа поиска с тремя переключателями, по одной для каждого типа транспортного средства, которое хочет найти пользователь, например, радио для автомобиля, pushbike или лодки. На одной и той же странице у нас есть три отдельных раздела, все они видимы для пользователя, где пользователь может предоставить подробную информацию о том, чтоНапример, если пользователь хочет получить список автомобилей, есть возможность указать регистрационный номер или изготовить модель и т. д., и если пользователь хочет найти поля для ввода данных о яхте, в них можно указать информацию о названии лодки или пристани для яхт и т. д.
Есть одна кнопка поиска. Теперь я хочу получить совет о том, как наилучшим образом разместить слои для доступа к этой банке, выполнить вызов и показать результаты.
Ниже описано, как я к ней подхожу
У меня есть SearchBean, который является JSFУправляемый бин.
У меня есть три класса CarSearchRequest, PushBikeSearchRequest и BoatSearchRequest, каждый из которых имеет наборМетод arch ().
Затем у меня есть три сеансовых компонента без сохранения состояния CarDAO, PushBikeDAO и BoatDAO, каждый из этих DAO выполняет вызов метода в данном jar, например, CarDAO сделает вызов API, который возвращаетcar и т. д.
Каждый из трех указанных выше классов запросов имеет собственный конструктор по умолчанию, и только общедоступный конструктор принимает в качестве аргумента соответствующий DAO.
Затем в моем SearchBean после ввода трех DAO, которые являются EJB-компонентами.а в @PostConstruct методе я инициализирую все три объекта Request и передаю DAO их конструкторам.
Затем кнопка поиска на экране вызывает метод search () searchBean, который выглядит примерно так: 

public void search()
{
  //Vehicle is an enum whose value is selected by radi button
  if(this.vehicle.isCar())
  {
    carRequest.search();
  }
  else if(this.vehicle.isPushBike())
  {
    pushBikeRequest.search();
  }
  //boat checks and calls here ...

}

Я ненавижу это, если заявления в этом поиске хорошего дизайна не нуждаются в этой проверке.
Я не уверен, но вызов dao search из объекта запроса звучит anti-pattern. Это вообще хороший подход?
Кажется, я создаю 6 классов (3 Request Objects и 3 DAO), что опять-таки не звучит правильно.ics, поскольку каждая реализация поиска отличается.

Может кто-нибудь, пожалуйста, дайте мне лучший подход или любой соответствующий совет.

1 Ответ

0 голосов
/ 07 сентября 2011

я разрабатываю приложение с использованием JSF2 и EJB3, а я не использую CDI.

Мой совет связан с CDI.Почему вы решили не использовать его?Не используя CDI, вы теряете две самые фундаментальные новые услуги, предоставляемые JEE6 в веб-разработке JSF: контексты и внедрение зависимостей.Вы можете работать исключительно с EJB 3.1, но у вас не будет простейшего возможного решения.Тогда я бы начал с CDI, если мне понадобятся другие требования, такие как транзакции, jmx, пул и т. Д., Тогда EJB придет вам на помощь

...