Методы продюсера против именованных классов - PullRequest
Новая
       3

Методы продюсера против именованных классов

6 голосов
/ 29 февраля 2012

Интересно, какой путь предпочтительнее: получить доступ к вспомогательным переменным бина по полному classname.property или получить прямой доступ только к имени свойства по методу продюсера? Особенно, если проект становится намного больше с большим количеством классов, услуг, фасадов и т. Д. 

@Named
public Service {
    List<Customer> getCustomers();
}

use:
<h:dataTable value="#{service.customers}" />

или 

public Service {
    @Produces
    @Named
    List<Customer> getCustomers();
}

use:
<h:dataTable value="#{customers}" />

Первое преимущество для меня заключается в том, что если мне нужно изменить jsf, я всегда точно знаю, какой класс мне нужно изменить, из-за полного имени.

Это будет недостатком для 2-го способа, но, в отличие от этого, лучше читать в случае многих служб и классов.

Что бы вы, эксперты, сказали?

Ответы [ 2 ]

0 голосов
/ 14 апреля 2012

Я бы выбрал первый вариант, так как мне нравится всегда ссылаться на управляемый компонент, который относится к странице.Я считаю, что это более понятный код.

0 голосов
/ 02 марта 2012

ИМО, я иду по первому маршруту.С рефакторингом также проще (при условии, что ваша IDE также будет переименована на страницах JSF).Хотя, честно говоря, я ожидал, что это будет личная вещь.

Еще одним преимуществом использования service.property является возможность изменять свойство и отражать его в пользовательском интерфейсе.Если вы используете производителя, этот производитель вызывается только один раз для каждой области, где как метод получения вызывается все время (другой компромисс производительности).Есть много способов сделать что-то, и, если у вас все хорошо, используйте этот способ.

...