JSF 백업 빈 구조(베스트 프랙티스)

JSF 백업 빈 구조(베스트 프랙티스)

이 투고에서는 JSF 페이지와 backing beat 사이의 인터페이스의 베스트 프랙티스에 대한 사람들의 의견을 얻을 수 있기를 바랍니다.

내가 절대 정착할 수 없는 한가지는 내 등콩의 구조이다.게다가, 나는 그 주제에 대한 좋은 기사를 발견하지 못했다.

어떤 성질이 어떤 콩에 속합니까?새로운 콩을 만들어 콩에 속성을 추가하는 것이 아니라 특정 콩에 속성을 추가하는 것이 적절한 때는 언제입니까?간단한 어플리케이션에서는 하나의 빈을 다른 빈에 삽입해야 하는 복잡함을 고려하여 페이지 전체에 대해 하나의 빈을 백업하는 것이 의미가 있습니까?backing bean에는 실제 비즈니스 로직이 포함되어 있어야 합니까, 아니면 데이터를 엄격하게 포함해야 합니까?

이 질문들과 다른 질문들에 대해 자유롭게 답변해 주세요.

---

JSF 페이지와 backing bean의 결합을 줄이는 것에 대해서는, backing bean 속성에 JSF 페이지가 액세스 하는 것을 절대로 허용하지 않습니다.예를 들어, 저는 절대 다음과 같은 것을 허용하지 않습니다.

<h:outputText value="#{myBean.anObject.anObjectProperty}" />

항상 다음과 같은 것이 필요합니다.

<h:outputText value="#{myBean.theObjectProperty}" />

backing bean 값:

public String getTheObjectProperty()
{
    return anObject.getAnObjectProperty();
}

예를 들어 컬렉션을 루프할 때 데이터 테이블의 객체로 드릴다운되는 것을 방지하기 위해 래퍼 클래스를 사용합니다.

일반적으로, 이 어프로치는 나에게 「적당」하게 느껴집니다.보기와 데이터 간의 결합을 방지합니다.제가 틀렸다면 정정해 주세요.

JSF 관리 대상 콩의 종류를 구분하는 것이 좋습니다.

다음은 Neil Griffin의 위 기사에서 정의한 다양한 콩 종류에 대한 설명입니다.

• Managed-Bean 모델: 보통 세션 범위입니다.이러한 유형의 managed-bean은 MVC 설계 패턴의 "모델" 문제에 관여합니다."모델"이라는 단어가 보이면 DATA를 생각해 보세요.JSF model-bean은 속성을 캡슐화하는 getters/setters를 사용하여 JavaBean 설계 패턴을 따르는 POJO여야 합니다.bean 모델의 가장 일반적인 사용 사례는 데이터베이스 엔티티가 되거나 데이터베이스 쿼리의 결과 집합에서 행 집합을 나타내는 것입니다.
• Managed-Bean 백업: 일반적으로 범위를 요청합니다.이 유형의 managed-bean은 MVC 설계 패턴의 "보기" 문제에 관여합니다.backup-bean의 목적은 UI 로직을 지원하는 것이며, JSF 뷰 또는 페이스릿 구성의 JSF 형식과 1:1 관계를 가집니다.일반적으로 연결된 getter/setter와 함께 JavaBean 유형 특성을 가지지만, 이러한 특성은 기본 응용프로그램 데이터 모델이 아닌 보기의 특성입니다.JSF backing-beans에는 JSF actionListener 메서드와 valueChangeListener 메서드도 있습니다.
• Controller Managed-Bean: 보통 범위를 요구합니다.이러한 유형의 managed-bean은 MVC 설계 패턴의 "컨트롤러" 문제에 관여합니다.컨트롤러 bean의 목적은 일종의 비즈니스 로직을 실행하고 탐색 결과를 JSF 탐색 핸들러로 반환하는 것입니다.JSF 컨트롤러 beans에는 일반적으로 JSF 액션메서드가 있습니다(actionListener 메서드는 없습니다.
• Support Managed-Bean: 보통 세션 또는 응용 프로그램 범위입니다.이 유형의 빈은 MVC 설계 패턴의 "보기" 관심사에서 하나 이상의 보기를 "지원"합니다.일반적인 사용 사례는 여러 JSF 보기에 나타나는 JSF h:selectOneMenu 드롭다운 목록에 ArrayList를 제공하는 것입니다.드롭다운 목록의 데이터가 사용자에게 고유한 경우 빈은 세션 범위 내에 유지됩니다.단, 데이터가 모든 사용자에게 적용되는 경우(예: 지방의 드롭다운목록), 빈은 모든 사용자에게 캐시될 수 있도록 응용 프로그램 범위 내에 유지됩니다.
• 유틸리티 관리 빈: 통상의 애플리케이션 범위.이 유형의 빈은 하나 이상의 JSF 보기에 몇 가지 유형의 "유틸리티" 기능을 제공합니다.이를 위한 좋은 예로는 여러 웹 애플리케이션에서 재사용할 수 있는 FileUpload bean이 있습니다.

좋은 질문입니다.JSF로 옮겼을 때도 같은 딜레마에 시달렸습니다.정말 신청에 따라 다르죠.저는 Java EE 세계 출신이기 때문에 가능한 한 비즈니스 로직은 사용하지 않는 것이 좋습니다.이 논리가 순전히 페이지 표시와 관련된 것이라면 backing bean에 저장해도 됩니다.

JSF의 장점 중 하나는 관리 대상 콩에 도메인 객체를 직접 노출할 수 있다는 것입니다. 때문에 는 꼭 메뉴입니다.<:outputText value="#{myBean.anObject.anObjectProperty}" />접근하지 않으면 각 속성을 수동으로 노출시키는 데 너무 많은 작업을 하게 됩니다.또한 모든 속성을 캡슐화하면 데이터를 삽입하거나 업데이트할 때 조금 혼란스러울 수 있습니다.단일 도메인 개체로 충분하지 않을 수 있습니다.이 경우 Value Object를 Bean에 공개하기 전에 준비합니다.

EDIT: 실제로 공개하는 모든 오브젝트 속성을 캡슐화하는 경우 UI 컴포넌트를 백업빈에 바인드하고 콘텐츠를 컴포넌트 값에 직접 삽입하는 것이 좋습니다.

콩의 구조에 관해서는 웹 어플리케이션 구축에 대해 알고 있던 것을 모두 무시하고 GUI 어플리케이션으로 취급하기 시작한 것이 계기가 되었습니다.JSF는 Swing을 많이 모방하기 때문에 Swing 어플리케이션 개발의 베스트 프랙티스는 JSF 어플리케이션 구축에도 적용됩니다.

당신의 지원 콩에서 가장 중요한 것은 논리를 분리하는 것이라고 생각합니다.CMS 시스템의 첫 페이지가 있는 경우, 다음과 같은 이유로 모든 코드를 하나의 빈에 넣는 것은 나쁜 관행이라고 생각합니다.

1. 콩은 결국 매우 크게 변할 것이다.
2. 로그인 페이지의 트러블 슈팅을 실시하고 있는 경우, loginBean.java 파일을 간단하게 검색할 수 있으면, 다른 유저가 찾고 있는 것을 간단하게 찾을 수 있습니다.
3. 코드와 다른 기능이 명확하게 구별되는 작은 부분이 있을 수 있습니다.이것을 분리하면, 이미 좋은 구조의 빈을 가지고 있는 경우, 이 코드를 보다 큰 것으로 재개발/확장하는 것이 편리해질 것입니다.
4. LoginBean LoginBean = new LoginBean()을 실행함으로써 실제로 필요한 펑크존성을 사용하는 대신 MyBigBean = new MyBigBean()과 같은 선언을 수행해야 할 경우 빅빈 1개가 있으면 메모리에 더 의존하게 됩니다.?)
5. 내 생각에, 콩을 분리하는 것은 방법을 분리하는 것과 같다.100개 이상의 회선을 실행하는 하나의 큰 메서드가 아니라 특정 태스크를 처리하는 새로운 메서드로 분할해야 합니다.
6. 대부분의 경우 JSF 프로젝트에서도 작업해야 합니다.

---

As for the coupling, I dont see it as a troublesome issue to allow your JSF pages access too the properties in objects in your backingbean. This is support which is built into JSF, and really just makes it easier to read and build imo. Your allready separating the MVC logic strictly. By doing this your saving yourself tons of lines with getters and setters in your backingbean. For example I have a really huge object given to me by the web services, where I need to use some properties in my presentation. If I were to make a getter/setter for each property my bean would expand with atleast 100 more lines of variables and methods for getting the propeties. By using the built in JSF functionality my time and precious code lines are spared.

이 문제에 대한 나의 2센트만 이미 답변으로 표시되어 있다.

케이스 투 케이스에 의존하는 사람은 거의 없기 때문에 당신의 모든 질문에 대답할 수 없습니다.

• 이것은 사업 논리를 뒷받침하는 것이 좋습니다.어디서 오느냐에 따라 다르죠.도메인 중심 설계를 실천하고 있는 경우, 비즈니스 로직을 backing bean에 포함시키고 싶은 유혹이 생기거나 영속적인 로직일 수도 있습니다.그들은 왜 그렇게 멍청한 물건인지 주장한다.사물은 상태뿐만 아니라 행동도 포함해야 합니다.한편, Java EE의 종래의 작업 방식을 생각하면, 백업 빈(Entity Bean)이나 세션 빈(session bean)에 데이터가 있는 것처럼 느껴질 수 있습니다.그것도 괜찮아요.

• 한 페이지 전체에 백킹빈을 한 장씩 넣어도 전혀 문제가 없습니다.이것만으로는 문제가 없다고 생각합니다.이건 옳지 않아 보일 수도 있지만 경우에 따라 다르죠.

• 또 다른 질문은 담당 케이스에 따라 크게 달라집니다.도메인으로 이동하는 것이 좋습니다.기존에 속성을 추가하거나 새로운 bean을 작성하는 것이 적절할 수 있습니다.어느 쪽이 더 잘 어울리는지.나는 이것에 대한 어떤 실탄도 없다고 생각한다.

• 어떤 속성이 어떤 backing bean에 속합니까?도메인 오브젝트에 의존하지 않나요?아니면 질문이 그렇게 명확하지 않을 수도 있다.

또, 당신이 제시한 코드 예에서는, 큰 메리트는 보이지 않습니다.

백킹빈을 한 장에 한 장씩만 보관할 필요는 없습니다.기능에 따라 다르지만, 대부분의 경우 한 페이지에 한 개의 빈이 있기 때문에 한 페이지에 한 개의 빈을 가지고 있었습니다.예를 들어 페이지에는 Register Link(RegisterBean과 링크)와 쇼핑 바구니 링크(ShoopingBasketBean)가 있습니다.

이 <:출력>을 사용합니다.텍스트 값="#{myBean.anObject.anObjectProperty}" /> 데이터 객체를 유지하는 액션빈으로서 콩을 계속 백업하고 있습니다.데이터 객체의 속성에 액세스하기 위해 백킹빈에 래퍼를 쓰고 싶지 않습니다.

View를 사용하지 않고 비즈니스 코드를 테스트하는 것을 좋아하기 때문에 BackingBeans를 View에서 Model 코드로의 인터페이스로 생각합니다.BackingBean에는 규칙이나 프로세스를 넣지 않습니다.이 코드는 서비스 또는 도우미에 들어가 재사용이 가능합니다.

검증자를 사용하는 경우 검증자를 BackingBean에서 삭제하고 검증 메서드에서 참조합니다.

Selects, Radios, Checks를 채우기 위해 DAO에 액세스하는 경우 항상 BackingBean에서 이 작업을 수행합니다.

날 믿어!JavaBean을 BackingBean에 삽입할 수 있지만 BackingBean을 다른 Bean에 삽입해 보십시오.당신은 곧 유지 보수와 이해의 골칫덩어리가 될 것입니다.

언급URL : https://stackoverflow.com/questions/746047/jsf-backing-bean-structure-best-practices