Spring 의 관점 에서 POJO 를...

글 목록

서문

POJO 가 뭐 예요?

왜 포 조 가 나 왔 을 까?

가장 기본 적 인 POJO

POJO 의 실제 응용

머리말
POJO 에 대한 정 리 를 하고 싶 었 는데 POJO 가 개발 에서 도대체 무엇 입 니까?포 조 는 왜?POJO 는 개발 에서 어떤 부분 에 나타 나 고 있 나 요?이것 은 제 가 항상 관심 을 가 졌 던 것 입 니 다.처음에 자 바 를 접 했 을 때 저 는 이 POJO 의 개념 에 대해 깊이 이해 하지 못 하고 개념 에 만 머 물 렀 습 니 다.제 가 자바 에 대해 깊이 이해 하면 서 Spring 에 게 서 POJO 의 그림 자 를 보 았 습 니 다.그래서 Spring 에서 제 가 POJO 에 대한 이 해 를 말씀 드 리 고 싶 습 니 다.내용 이 깊 지 않 습 니 다.여기 서 저 는 Spring 에 대해 전문 적 으로 이야기 하고 싶 지 않 습 니 다.기본 적 인 사용 측면 에서 POJO 를 논 하고 Spring 디자인 이념 의 일부 표현 도 이해 할 수 있다.
포 조 가 뭐야?
POJO,즉"Plain Old Java Object"입 니 다.우 리 는 POJO 가 순수한 자바 대상 이 고 무엇이 순수한 자바 대상 이 라 고 생각 할 수 있 습 니까?자바 언어 규범 을 바탕 으로 디자인 된 대상 이 바로 POJO 입 니 다.더 나 아가 POJO 는 관련 제3자 인 터 페 이 스 를 실현 하지 못 하고 관련 제3자 클래스 를 계승 하지 못 한 자바 대상,즉 비 침입 자바 대상 을 말 하 는 것 으로 이해 할 수 있다.
포 조 는 왜 나 와 요?
POJO 는 예전 의 EJB 개발 모델 에서 말 할 수 있다.Spring 이전에 EJB 가 주도 한 개발 모델 에서 EJB 개발 자 는 J2EE 규범 에 따라 실 현 된 J2EE 응용 서버 에 의존 해 야 하고 구체 적 으로 실현 할 때 일련의 인터페이스 기준 을 따라 야 한다.그래 야 응용 서버 의 환경 에서 테스트 와 배 치 를 받 을 수 있다.(특히 테스트 환경 은 규범 화 된 인 터 페 이 스 를 제정 하 는 호출 에 의존 하기 때문에 EJB 규범 에서 디자인 된 각종 유형 은 대부분이 침입 식 에 속한다.즉,그들 은 관련 인 터 페 이 스 를 실현 하고 관련 된 부 류 를 계승 하 며 간단 하고 순수한 유형 이 아니 라 업무 와 밀접 하 게 연결된다.한편,Spring 디자이너 는 J2EE without EJB 를 제창한다.바로 POJO 의 디자인 사상 을 바탕 으로 우 리 는 업무 시스템 에서'순수한'유형 을 디자인 하 게 한다.그들 은 자바 언어 규범 에 부합 되 는 간단 한 자바 대상 일 뿐이다.이렇게 하면 예전 EJB 의 복잡 한 개발 절차 에서 벗 어 나 우리 가 개발 한 입문,테스트,응용 배 치 는 모두 간소화 되 었 다.
가장 기본 적 인 포 조.
예 를 들 어 간단 한 User 클래스:

public class User {
     
	private long id;
	private String name;
	public void setId(long id) {
     
		this. id = id;
	}
	public void setName(String name) {
     
		this. name=name;
	}
	public long getId() {
     
		return id;
	}
	public String getName() {
     
		return name;
	}
}

상기 한 것 은 바로 간단 한 POJO 로 다른 업무 구조 와 결합 되 지 않 았 다.예 를 들 어 특정한 업무 구 조 를 실현 하 는 인터페이스,관련 업무 류 를 계승 하 는 등 자바 언어 규범 에 따라 관련private속성 을 간단하게 정의 하고 기본 적 인getter,setter대외 노출 인터페이스 가 이 대상 에 대한 기본 적 인 조작 을 제공 하 는 것 에 불과 하 다.
POJO 의 실제 응용
왜 POJO 의 디자인 이 개발 을 더욱 간소화 할 수 있다 고 말 합 니까?사실은 본질 적 으로 우리 가 개발 에서 핵심 적 인 POJO 를 정의 하 는 것 이다.예 를 들 어 위의 User 류 는 우리 의 업무 와 관련 되 고 사용자 데이터 에 대한 적재 류 이지 만 우 리 는 대상 을 대상 으로 하 는 디자인 이념 을 간단하게 바탕 으로 사용 자 를 하나의 User 류 로 추상 화하 고 사용자 와 관련 된 속성 묘 사 를 가진다.이때 대상 을 대상 으로 하 는 OO,기본 적 인 자바 언어 규범 과 기본 적 인 개발 규범(속성 private,대외 getter,setter)은 기본 적 인 POJO 를 완성 했다.다른 사람들 이 보기에 그것 은 순수한 자바 대상 일 뿐 기본 적 인 속성 과 방법 이 있다.상기 기본 적 인 POJO 의 디자인 을 바탕 으로 지금 은 우리 의 업무 에 지원 을 제공 할 수 없 지만 우 리 는 이 를 바탕 으로 끊임없이 확장 하여 우리 의 업무 시스템 에 계속 적합 하 게 할 수 있다.예 를 들 어 현재 우리 시스템 은 관련 된 인증,감 권 이 필요 하 다.그러면 우 리 는 이 POJO 가 Spring Security 특유 의UserDetail인 터 페 이 스 를 실현 할 수 있다.이때 이 는 일반적인 POJO 에서 시스템 안전 과 관련 된 업무 유형 으로 바 뀌 었 다.만약 에 우리 가 시스템 안전 과 관련 된 시스템 디자인 을 하 는 것 이 아니 라 데이터베이스 사용자 표 의 데이터 적재 가 되 려 고 한다 면 우 리 는 이 를 수정 하지 않 고 데이터 베 이 스 를 조회 하고 관련 된 데이터 캐리어 를 삽입 할 수도 있다.이때 이 두 가지 응용 장면 의 예 는 모두 POJO 를 바탕 으로 확 장 된 것 이다.POJO 의 간단 한 특징 을 바탕 으로 우 리 는 개발 할 때 POJO 를 바탕 으로 고도 의 확장 성 을 가지 고 서로 다른 방향의 디자인 을 완성 할 수 있다.이것 이 바로 Spring 이 제창 하 는 POJO 개발 방식 이다.
또 다른 설명 할 수 있 는 예 는 바로 SpringMVC 이다.원래 J2EE 규범 에서 웹 개발 을 할 때 우 리 는 특정한 업무 에 따라 유형Servlet을 설계 하 는데 웹 용기 에 의 해 관리 되 는 것 을 지원 하기 위해 보통 우 리 는 계승HttpServlet한다.예 를 들 어:

public class FooHttpServlet extends HttpServlet {
     
       @Override
       public void init() throws ServletException {
     
	            // code 
       }
       @Override
       protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
     
               // code
       }
       @Override
       protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
     
               // code
       }
}

상기FooHttpServlet는 POJO 가 아니다.특정한 규범HttpServlet추상 류 를 계승 하기 때문에 우 리 는 이런 종류 가 이미 침입 되 었 다 고 생각 할 수 있 기 때문에 특정한 장소(Web)에 만 사용 할 수 있다.
그러나 SpringMVC 디자인 이념 에서DispatcherServlet를 핵심 으로 하 는 MVC 모델 로 디자인 된 Controller,예 를 들 어:

public class FooController {
     
		public void methdA(){
     
			// code
		}
}

이것 은 바로 POJO 입 니 다.그 자체 가 관련 인터페이스,계승 과 관련 된 유형 등 을 실현 하지 못 했 기 때문에 SpringMVC 차원 에서 우 리 는 이 POJO 가 역할 을 하도록 해 야 합 니 다.우 리 는 XML 에 Bean 을 배치 하 는 방식 으로 IOC 용 기 를 시작 할 때 스 캔 하고 용기 에 넣 으 면 서 비 스 를 제공 할 수 있 습 니 다.이것 이 바로 Spring 이 제창 해 온 POJO 개발 모델 의 구체 적 인 표현 중 하나 입 니 다.이런 방식 은 상당히 간결 하 다.만약 에 POJO 가 아니 라 관련 인터페이스,계승 과 관련 된 유형 도 실현 했다 면 우 리 는 사용 할 때 이런 인터페이스 규범 등 을 알 아야 한다.그러면 개발 할 때 복잡성 이 생 겼 고 간단 한 POJO 는 우 리 는 이런 차원 에 머 물 러 야 한다.비교 해 보면 POJO 의 장점 이 나타난다.
물론 현재 실제 개발 에서 우 리 는 POJO 의 디자인 방식 에 완전히 따 르 지 않 을 것 이다.예 를 들 어 위의FooController우 리 는 XML 에 전문 적 으로 배치 하지 않 고 위 에서 설명 하 는 방식 이다.

@Controller
public class MyController {
     
		public void methdA(){
     
			// code
		}
}

POJO 의 정의 에 따라 엄 격 히 이해 하면 이 때 는 POJO 가 아 닙 니 다.그러나 전체적으로 보면 J2EE 개발 모델 에서 Servlet 을 사용 하 는 것 보다 상당히 간결 합 니 다.상기 한 것 은 엄 격 히 POJO 가 아니 지만 POJO 를 바탕 으로 확장 되 었 다 고 볼 수 있 습 니 다.Spring 은 POJO 나 POJO 를 바탕 으로 확장 되 는 개발 모델 을 해 야 합 니 다.먼저 해 야 할 일 은 원래 의 특정한 장소(예 를 들 어 웹)의 규범 에서 위로 추상 화 하 는 것 이다.추상 층 을 구축 함으로써 우 리 는 최상 위 에서 디자인 이 간단 한 POJO 나 POJO 확장 대상 을 바탕 으로 응용 기능 의 디자인 을 완성 할 수 있 고 Spring 의 관련 응용(예 를 들 어 MVC,Security)을 바탕 으로 중간 층 의 복잡 한 전환 을 완성 하 는 데 도움 을 줄 수 있다.그 실현 의 핵심 은 바로 개발 과정 에서 직면 한 공통점 문 제 를 추상 화 에 집중 시 키 고 Spring 은 추상 층 을 실현 하여 개발 자 에 게 최소한 의 디자인 원 가 를 제공 하 는 것 이다.즉,가장 간단 한 POJO 를 디자인 하여 응용 개발 을 완성 하 는 것 이다.이것 이 바로 Spring 이 원 하 는 것 이다.