[SPRING] 웹 아키텍처 : MVC, 지연 초기화 (Lazy initialization), 데이터 전송 객체, 열린 세션보기에서 컨센서스 접근법이 있습니까?

웹 아키텍처 : MVC, 지연 초기화 (Lazy initialization), 데이터 전송 객체, 열린 세션보기에서 컨센서스 접근법이 있습니까?

일반적인 웹 3-tier 애플리케이션의 다음 설계에서 어떤 결함이 보이는지 (그리고 이상적인 아키텍처 제안이 무엇이겠습니까?)

현재의 청사진 접근법은 매우 대략적입니다 (Java, Spring, Hibernate, JSP라고 가정)

잠재적으로 래이 트 초기화 예외를 피하기 위해 읽기 전용 트랜잭션으로 래핑 된 상태 비 저장은 서비스를 통해서만 지속 저장 영역에서 엔티티를 가져 와서 뷰로 모델로 전달합니다. BL이 서비스 계층에만 있어야합니까?) 비즈니스 로직을 수행하고 필요한 경우 지속성을 위해 서비스 계층으로 전달합니다.

장점 : 읽기 전용 트랜잭션 래핑 - 하나의 연결, 동일한 영구 엔터티에 대한 중복 적중률 없음, 쿼리 캐시를보다 잘 활용함, 서비스 계층이 요청 매개 변수 또는 필요한 초기화 그래프 범위를 "알지 못함", 지연 초기화 예외 방지.

단점 : 읽기 전용 트랜잭션 접근 방식은 위험 할 수 있으며 컨트롤러는 이상적인 비즈니스 로직 매달린 장소가 아닙니다 ... JUnits를 수행하기가 매우 어렵습니다 (입력 내용은 요청입니다 ...)

비 트랜잭션 (비 게으른 콜렉션 / 멤버에 대한 액세스는 lazy init 예외가 발생합니다)

장점 :

단점 : 컨트롤러 / 서비스 / DAO는 뷰에 대한 엔티티의 올바른 그래프를주의 깊게 준비해야하며 초과 실행 (성능) / 언더 슈팅 (지연 초기화 예외) 일 수 있습니다. 무수히 많은 서버 측 방법으로 엔티티 그래프를 초기화 할 수있는 순열의 수에 데카르트 곱이 있기 때문에 혼란을 야기 할 수있다.

영구 객체를 그대로 사용하면 (데이터 전송 객체 없음) 상태가 세션에 저장됩니다.

장점 : POJO를 재 작성할 필요가없고 기존 엔티티를 재사용 할 수 있으며 세션 상태는 숨겨진 필드 상태 처리보다 안전합니다.

단점 : 연결이 끊어진 프레임 워크, 연결이 끊긴 개체를 저장하는 위험, 잠금 문제의 위험, 다른 데이터의 무시 위험은 때때로 낙관적 잠금을 필요로합니다.

트랜잭션, 요청 범위를 알지 못한다면, 실제 영속 스토리지 접근을 위해 DAO 계층을 호출한다. 이것은 BL이 고전적으로 있어야하는 곳이지만, 컨트롤러 측에 BL 누수가 계속 반복되는 것 같습니다.

BL의 무지 또는 모든 컨텍스트를 포함하는 원자 지속성 저장소 외관을 포함합니다.

위의 아키텍처에서 무엇을 수정하겠습니까?

당신은 (나 같은) 그것이보기에 열려있는 세션과 같은 약간의 차이점을 가지고 꽤 일반적인 접근이라고 생각합니까? 아니면 처음 보는가? 나는 끔찍한 잘못 (또는 옳은 일)을하고 있는가?

귀하의 응용 프로그램에서 어떻게 해결합니까? 모델과 뷰에도 엔터티 POJO를 사용합니까? 아니면 간단한 UI bean (완전히 초기화되고 안전하게)에 연결시켜 주겠습니까?

이것은 주관적인 질문 일지 모르지만, 하나, 둘 또는 세 개의 일반 "종교"에 클러스터되는 명확한 모범 사례 디자인 패턴이있을 것이라고 확신합니다.

해결법

1. ==============================

   1.전반적으로 이것은 매우 훌륭한 아키텍처처럼 보입니다. 아직 읽지 않았다면 마틴 파울러 (Martin Fowlers)의 엔터프라이즈 응용 프로그램 아키텍처 (Enterprise Application Architecture) 패턴을 참고하여 질문의 모든 주제를 설명하십시오.

   전반적으로 이것은 매우 훌륭한 아키텍처처럼 보입니다. 아직 읽지 않았다면 마틴 파울러 (Martin Fowlers)의 엔터프라이즈 응용 프로그램 아키텍처 (Enterprise Application Architecture) 패턴을 참고하여 질문의 모든 주제를 설명하십시오.

   의문의 여지가 얼마나 큰 이슈가 당신이 기대하는 바는 분명하지 않습니다. 내 경험에 비추어 볼 때 성능 병목 현상은 거의 존재하지 않는다고 생각하는 경우가 거의 없으며 빨리 찾을수록 아키텍처를 쉽게 변경하여 변경할 수 있습니다.

   테스트 가능성이 주요 관심사라는 것은 맞습니다. 필자는 Martin Fowlers Passive View 패턴을 약간의 성공을 거두었습니다. 같은 사이트에서 감독 컨트롤러를 살펴보아야합니다.

2. ==============================

   2.Super는 SOFEA 스타일의 프런트 엔드를 사용하지 않는 한 기본적으로 위의 아키텍처에서 컨트롤러 부분을 제거합니다.

   Super는 SOFEA 스타일의 프런트 엔드를 사용하지 않는 한 기본적으로 위의 아키텍처에서 컨트롤러 부분을 제거합니다.

   프런트 엔드는 클라이언트에 완전히 포함되어 JSON 또는 XML을 반환하는 REST 또는 SOAP 서비스를 직접 호출합니다. 그 표시 도메인 개체를 변환하는 문제의 100 %를 해결하는 것!

   어쩌면 위의 N 계층 아키텍처에 대한 명확한 해결책이없는 이유는 그것이 명백히 잘못 되었기 때문일 수도 있습니다.

   모래밭

   현재 프로젝트는 다소 오래된 N 계층 아키텍처를 데이터 전송 객체와 함께 사용합니다. DTO는 응용 프로그램이 배포되지 않고 결코 존재하지 않기 때문에 불필요합니다. DTO 사용의 이점 중 하나는 비즈니스 메소드에 대한 깨끗한 인터페이스를 강제한다는 것입니다. View 구성 요소는 의사 모델에서 객체 그래프를 탐색 할 수 있지만 원하는 경우 느리게 초기화 예외는 발생하지 않습니다. 던져 질거야.

   아키텍처에서 볼 수있는 아키텍처상의 문제점 중 하나는 비즈니스 인터페이스가 복잡하다는 것입니다. 모든 소규모 비즈니스 인터페이스를 캡슐화하기 위해 메타 비즈니스 인터페이스가 필요한 것처럼 보입니다. 실제로 이것은 하나의 서비스가 세 가지 다른 서비스를 호출하여 업무를 수행하는 곳에서 일어납니다.

   컨트롤러 (이 경우, Struts 1.2 Action 클래스)는 이러한 초 미세 또는 거친 비즈니스 구성 요소의 조합을 호출하게됩니다. 대부분의 경우, 슬프게도 개발자는 무의식적으로 또는 게으른 코드를 컨트롤러 클래스에 비즈니스 로직으로 포함시켜야합니다. 나는이 300 라인 행동 방법 중 하나를 볼 때마다 비명을 지른다. !!!!

   SOFEA 접근법은 훨씬 더 깨끗한 접근법을 제공하는 것으로 보인다. AJAX를 사용하면 브라우저에서 실행되는 웹 응용 프로그램도 적절한 MVC 패턴을 사용하여 프런트 엔드를 코딩 할 수 있습니다. 이는 사용자 (동적 UI 제공)와 개발자 (적절한 MVC를 코딩 할 수 있음) 모두에게 유용합니다.

   UI는 재사용 가능한 비즈니스 로직과 완전히 분리됩니다. GUI가 두껍거나 얇은가요? 정말로 중요하지 않습니다. 그들은 기본적으로 같은 방식으로 코딩됩니다.

   SOFEA / SOUI는 나에게 새로운 것이고 나는 한번도 해본 적이 없지만 최근에 그것에 대해 읽었으며 생각을 나누겠다고 생각했습니다.

3. ==============================

   3.위의 접근 방식이 좋게 들립니다.

   위의 접근 방식이 좋게 들립니다.

   하지만 UI Beans를 사용해야한다고 생각합니다. 물론이 UI 빈은 효과적으로 변경 가능해야합니다. 그것이 생성 되 자마자 그것의 상태 (그리고 캡슐화 된 도메인 객체)는 변경되어서는 안된다.

   매우 단순화 된 예 :

   
   class UIBean {
     DomainObject o;
   
     public String getDescription(){
        return trimToSummaryText(o.getDescription());
     }
   
     private static String trimForSummaryText(){
        ....
     }
   }
   
   

   주요 전문가 :

   예, 자바 클래스가 더 많이 포함되어 있습니다. 그러나이 추상화 계층은 웹 애플리케이션과 페이지가 성장하자마자 거의 항상 괜찮습니다.

4. ==============================

   4.질문에 대한 대답은 1 년 전쯤에 끝났다고 대답했지만 아마도 그 대답은 누군가에게 도움이 될 것입니다. 전반적으로 아키텍처에 의해 개괄적으로 설명 된 추가 세부 사항은 위의 언급 대신에 레이어 (예 :보기 및 서비스) 사이에서 데이터를 전달하기위한 것입니다. UiBean의 소위 DTO (데이터 전송 개체)가 사용되는이 POJO는 적절한 필드 / 세터 / 게터.

   질문에 대한 대답은 1 년 전쯤에 끝났다고 대답했지만 아마도 그 대답은 누군가에게 도움이 될 것입니다. 전반적으로 아키텍처에 의해 개괄적으로 설명 된 추가 세부 사항은 위의 언급 대신에 레이어 (예 :보기 및 서비스) 사이에서 데이터를 전달하기위한 것입니다. UiBean의 소위 DTO (데이터 전송 개체)가 사용되는이 POJO는 적절한 필드 / 세터 / 게터.

   Java EE 스펙의 이전 / 초기 버전 중 하나에서 "DTO"용어는 "ValueObject"와 실수로 섞여 있었지만 조금 다른 용도로 사용되었습니다.

   희망, 이것이 도움이됩니다.

from https://stackoverflow.com/questions/1969278/web-architecture-mvc-lazy-initialization-data-transfer-objects-open-session by cc-by-sa and MIT license