Так что, когда люди имеют несколько управляемых bean-компонентов, это только потому, что они хотят сгруппировать методы с одной и той же областью действия (RequestScoped, ApplicationScoped, SessionScope ...) вместе? Или есть какая-то другая причина?
Это зависит от данных, которые содержит бин, и от обязанностей бина. Если он содержит данные в области запроса (например, входные значения формы и действия формы), то компонент должен перейти в область запроса. Если он содержит данные области сеанса (например, вошедший в систему пользователь, пользовательские настройки, такие как локаль и т. Д.), То компонент должен войти в область действия сеанса. Если он содержит данные области приложения (например, значения раскрывающегося списка и другие константы всего приложения), то компонент должен войти в область приложения. Это логически логично.
Что произойдет, если вы введете управляемый бин с другим объемом в другой?
Вы можете внедрить bean-компонент только той же или более широкой области видимости в другой bean-компонент. Например. Компонент запроса, сеанса или приложения может быть введен в компонент запроса. JSF просто устанавливает его как свойство целевого компонента. Это не имеет побочных эффектов. JSF уже выдаст ошибку, когда вы попытаетесь внедрить бин более узкой области в другой бин. Вы не можете внедрить bean-объект с областью запроса в область сессий. Это имеет смысл. В одном и том же сеансе может быть более одного компонента с областью запроса, который JSF должен выбрать?
и почему они хотят внедрять один компонент с разными областями действия, могу ли я не просто получить доступ к другой базе компонентов JSF по своему усмотрению, а не вводить один компонент другому?
Это только добавит неприятный шаблонный код. Почему бы просто не позволить JSF сделать это прозрачно? Нет необходимости брать на себя ответственность JSF в свои руки. Инъекция обходится дешево, даже если вам не нужен инъекционный компонент в конкретном случае, это не повредит.