DO, DTO, BO, AO, VO, POJO가 정의하고 변환하는 올바른 자세

인용문

DO, DTO, BO, AO, VO, POJO의 개념은 간단해 보이지만 잘 구분하거나 이해하기가 쉽지 않다. 본고는 간단하게 요약한다.
각 계층의 POJO 사용을 통해 코드의 가독성과 유지보수성을 향상시키는 데 도움이 됩니다.
------------------------------------------------------------------------------------------------------------------------------------------------------

구별

《알리바바 자바 개발규범》의 영역 모델에 대한 부분은 다음과 같다.
계층형 영역 모델 규약:

DO(Data Object): 이 개체는 데이터베이스 테이블 구조와 일일이 대응하여 DAO 계층을 통해 데이터 소스 개체를 상향 전송합니다.

DTO(Data Transfer Object): 데이터 전송 객체, 서비스 또는 Manager 외부로 전송되는 객체입니다.

BO(Business Object): 서비스 레이어에서 내보내는 패키지된 비즈니스 논리의 객체입니다.

AO(ApplicationObject): 응용 대상, 웹 층과 서비스 층 사이의 추상적인 복용 대상 모델로 전시 층과 매우 가깝고 복용도가 높지 않다.

VO(View Object): 일반적으로 웹에서 템플릿 렌더 엔진 레이어로 전송하는 레이어 객체를 표시합니다.

Query: 데이터 조회 대상, 각 층은 상부의 조회 요청을 받는다.두 개 이상의 매개변수에 대한 쿼리 캡슐화에 주의하고 Map 클래스를 사용하여 전송하지 마십시오.

------------------------------------------------------------------------------------------------------------------------------------------------------
가장 이해하기 어려운 것은 BO입니다. 대체로 이렇게 이해합니다.
BO 객체에는 하나 이상의 다른 객체가 포함될 수 있습니다.
예를 들어 이력서는 교육 경력, 업무 경력, 사회 관계 등이 있다.
우리는 교육 경력을 하나의 PO에 대응하고 업무 경력은 하나의 PO에 대응하며 사회 관계는 하나의 PO에 대응할 수 있다.
이력서에 대응하는 BO 대상을 만들어 이력서를 처리하고 각 BO는 이런 PO를 포함한다.이렇게 업무 논리를 처리할 때 우리는 BO를 대상으로 처리할 수 있다.
------------------------------------------------------------------------------------------------------------------------------------------------------
대략적인 예제 코드:
Controller 레이어
public List getUsers(UserQuery userQuery);
이 레이어의 일반적인 변환: DTO-VO
서비스 레이어, Manager 레이어
//일반 서비스 계층 인터페이스
 List getUsers(UserQuery userQuery);
그리고 서비스 내부에서 UserBO를 사용하여 중간에 필요한 논리적 대상을 봉인합니다
//프런트엔드에서 요청
 List getUsers(UserAO userAo);
이 레이어의 일반적인 변환은 DO - BO, BO - DTO입니다.
DAO 계층
List getUsers(UserQuery userQuery);
------------------------------------------------------------------------------------------------------------------------------------------------------

3. 각종 대상은 어떻게 전환해야 합니까?

 
그렇다면 여기에는 또 다른 문제가 관련되어 있는데, 각종 대상의 전환은 어떻게 해야 합니까?
흔히 볼 수 있는 변환 방법을 쓰고 get/set 방법을 수동으로 호출하면 속성이 너무 많아서 매우 고통스럽고 누락되거나 중복되기 쉬우며 효율이 매우 낮다.
 
권장되는 두 가지 방법:
(1) 하나는 IDEA 플러그인을 통해 변환 코드를 신속하게 자동으로 생성하는 것이다.
Generate All setters 플러그인의 경우https://blog.csdn.net/w605283073/article/details/89163627
매개 변수와 반환 값을 정의하고 단축키로 변환된 코드를 쉽게 생성할 수 있습니다.
(2) 하나는 제3자 변환 라이브러리를 통해 변환하는 것이다.

Apache org.apache.commons.beanutils.PropertyUtils.copyProperties

Apache org.apache.commons.beanutils.BeanUtils.copyProperties

Spring org.springframework.beans.BeanUtils.copyProperties

Cglib BeanCopier

Dozer

orika

대응하는 마븐 의존 (마븐 주소가 주어졌으니 최신 버전을 사용하십시오)

    commons-beanutils
    commons-beanutils
    1.9.3





    org.springframework
    spring-beans
    5.1.6.RELEASE





    cglib
    cglib
    3.2.11





    net.sf.dozer
    dozer
    5.5.1





    ma.glasnost.orika
    orika-core
    1.5.4

 
효율적으로 다른 글을 읽은 적이 있는데 종합적으로 cglib이 가장 높고 그 다음은orika이다.
... 때문에
cglib은 asm를 사용하여 메모리 대상을 직접 조작하는 바이트 증강 기술을 사용합니다.
orika는javassist를 사용하여 동적 바이트 코드를 생성하여 대상 변환을 실현합니다.
 
구체적인 용법은 여기서 소개하지 않겠습니다. 필요하면 홈페이지에 가서 문서를 보고github에 가서 데모를 볼 수도 있습니다.
나의 견해:
두 번째 코드는 대상 전환이 간결하고 기능이 강하지만 저는 개인적으로 첫 번째 전환 방법을 쓰는 방식을 매우 추앙합니다. 왜냐하면 이런 방식의 대상 속성 변화는 코드에 직관적으로 반영될 수 있고 부주의와 속성 삭제 등으로 인해 발생하는 알 수 없는 오류를 피할 수 있기 때문입니다.
 
만약 이 글이 당신에게 도움이 된다고 생각한다면, 칭찬과 평론을 환영하고, 저를 주목해 주십시오. 저는 더 많은 더 좋은 글을 창작하려고 노력할 것입니다.