POJO(Plain Old Java Object) 기반 개발
- EJB는 프레임워크와 서버 환경에 의존적인 코드가 많았다
- 설정 파일 또한 난해했다
- 원래는 개발자가 비즈니스 로직에만 집중할 수 있도록 EJB가 로우 레벨 관리를 대신하게 할 목적이었다
- 그러나 EJB 코드는 EJB의 인터페이스와 클래스를 상속하는 방식으로 개발되었기 때문에 코드가 EJB 환경에 종속되고 추가로 상속이 되지 않아 객체지향적으로 개발을 하지 못하게 되는 부작용을 초래했다
- Spring은 서비스 추상화를 통해 코드에서 프레임워크와 환경에 의존적인 부분을 제거했다
- 추상화로 로우 레벨의 기술 구현을 분리하고 독립적으로 접근할 수 있는 인터페이스를 제공한다
- 그 결과, POJO(Plain Old Java Object)로 비즈니스 로직을 개발할 수 있게 되었다
- 예를 들면,
@Bean
Annotation으로 Plain 클래스에 Spring 코어가 식별할 수 있는 식별자를 달면 Spring Core가 실행될 때 전체 파일에서@Bean
이 달린 클래스를 찾고, 인스턴스를 생성하는 것으로 이해했다. @Bean
은 단순히 식별자(이름표) 역할만 하고 실제 동작은 Spring Core가 하는 것이다. 이 Annotation은 원래 Plain Object를 확장하는 것을 방해하지 않는다.- ChatGPT가 구현한 Bean 스캔 코드
- 예를 들면,
private static void scanDirectory(File directory, String packageName, List<Class<?>> beanClasses) {
for (File file : directory.listFiles()) {
if (file.isDirectory()) {
scanDirectory(file, packageName + "." + file.getName(), beanClasses);
} else if (file.getName().endsWith(".class")) {
String className = packageName + "." + file.getName().replace(".class", "");
try {
Class<?> clazz = Class.forName(className);
if (isBean(clazz)) {
beanClasses.add(clazz);
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
}
POJO 프로그래밍의 조건
- 특정 규약에 종속되지 않는다
- 특정 클래스를 상속하는 방식으로 구현되면 Java의 단일 상속 제한 때문에 객체지향적인 설계를 적용하기 어려워진다
- 규약이 적용된 환경에 종속되기 때문에 다른 환경으로 이전이 힘들어진다
- 특정 환경에 종속되지 않는다
- ex) EJB3의 빈의 의존 오브젝트 정보는 JNDI를 통해 가져와야 한다. JNDI가 없는 환경에서는 사용하기 힘들다
- 비즈니스 로직을 담당하는 POJO 클래스(Service)는 웹의 환경 정보와 웹 기술을 담고 있는 클래스나 인터페이스를 사용해서는 안 된다
- 그렇게 하면 웹 이외의 클라이언트에서 사용할 수 없고, 웹 서버에 올리지 않고 독립적으로 테스트하기 어려워진다
- 메타 정보를 추가해주는 Annotation은 환경에 종속되지만 않는다면 여전히 POJO라고 할 수 있다.
- 예를 들면,
@Service
,@Controller
이 자체가 하는 일은 단순히 이름표만 달아주는 것이고, Spring Core가 이름표 있는 클래스를 찾아서 원하는 동작을 수행하는 것으로 이해했다. @Service
,@Controller
가 단순히 이름표라면 이 코드를 그대로 복사해서 같은 Annotation을 사용하는 프레임워크에서도 동작할 것이다. 세부 구현이 다르더라도.
- 예를 들면,
- 객체지향적인 원리에 충실해야 한다
- 언어가 객체지향적인 기능을 지원해도 클래스 하나에 모든 기능을 쓴다던가 하는 식으로 객체지향적 설계를 하지 않으면 POJO라고 부르기는 힘들다.
POJO의 장점
- 특정한 환경과 기술에 종속되지 않기 때문에 비즈니스 로직만 남긴 깔끔한 코드를 개발할 수 있다
- 비즈니스 로직에 집중할 수 있다
- 자동화 테스트에 유리하다
- EJB는 의존성 때문에 테스트하려면 서버 구동, 빌드, 배치 과정까지 필요하다'
- 반면 POJO로 개발된 Spring은 독립적인 테스트가 가능하다
- 객체지향적인 설계를 자유롭게 적용할 수 있다
참고 자료
- 이일민, 『토비의 스프링 3.1 Vol.1』, 에이콘출판사, 2022, 732-739
'Spring Framework' 카테고리의 다른 글
[Spring][스크랩] Spring Boot Actuator, Prometheus, Grafana를 사용한 모니터링 환경 구축 (0) | 2024.04.08 |
---|---|
[Spring][Fix] Spring Boot Actuator - /info에 application 속성 나오지 않을 때 (0) | 2024.04.08 |
[Spring][스크랩] Spring Boot 공식 문서 (0) | 2024.04.08 |
[Spring][스크랩] Redis Session Storage 구현 (0) | 2024.03.28 |
[Spring] Spring의 장점 (EJB2와 비교) (0) | 2024.03.25 |