• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

스프링과 POJO에 대해 질문드리고 싶습니다.

23.06.26 17:55 작성 23.06.26 18:05 수정 조회수 270

0

선생님 안녕하세요
질문을 드리기 전에 스프링과 POJO에 대해 많이 찾아보고 고민했는데, 제가 제대로 이해한 게 맞는지 질문드리고 싶습니다.

저는 스프링이 POJO를 지향하는 프레임워크인 이유를 이렇게 이해했습니다.
엄밀히 말하면 DTO, VO처럼 인터페이스를 구현하지 않고 상위 클래스를 상속받지 않는 클래스들이 POJO라고 할 수 있습니다.

그러나 컨트롤러 클래스는 @Controller라는 어노테이션이 필요하기에, 스프링이라는 프레임워크에 종속된 기술이며, 서비스 클래스도 인터페이스(PSA)를 구현하기에 엄밀히는 POJO가 아닙니다.

그렇지만 POJO를 지향하는 이유가 결합도를 낮추고, 응집도를 높여 환경변화를 적게 받고 특정 기술에 종속되지 않기 위한 목적이 있습니다.

비록 컨트롤러 클래스와 서비스 클래스는 POJO라고 할 수는 없지만, 최대한 POJO에 가깝게 결합도를 낮추고 응집도를 높여서 재사용성을 높이기 위해 DI, AOP, PSA 를 사용했습니다.

즉, 완전한 POJO를 구현한 프레임워크는 아니지만, POJO를 지향하여 최대한 모듈 간 결합도를 낮추고 응집도를 높이고 재사용성을 높인 프레임워크라고 이해했습니다.

혹시 제가 제대로 이해했는지 봐주시면 감사하겠습니다.

답변 1

답변을 작성해보세요.

3

David님의 프로필

David

2023.06.27

안녕하세요. Like me black님, 공식 서포터즈 David입니다.

POJO는 상속이나 인터페이스 구현을 못하는 게 아닙니다. 자바 언어 스펙 외의 특정 기술에 종족되지 않아야 하는 것입니다.

스프링 프레임워크가 발전해 오면서 편의를 위해 여러가지를 지원하다보니 침투적으로 변하게 되었고 POJO라고 부르기에 힘든 부분도 있지만 애노테이션 방식이 아닌 xml 방식을 사용한다면 많은 객체들을 POJO 방식으로 만들 수 있습니다.

이외에는 잘 이해하고 계신 것 같습니다.

감사합니다.


선생님 가르쳐주셔서 감사합니다.
제가 선생님 말씀을 제대로 이해하기 위해 조금 더 찾아보고 고민해봤는데, 제대로 이해했는지 봐주시면 정말 감사하겠습니다.

1. 자바언어스펙은 자바의 표준 사양이며, Java SE 를 포함합니다.
2. HttpServlet은 자바언어스펙이 아닌, 확장 버전인 Java EE 이므로, HttpServlet을 상속받으면 POJO가 아닙니다.
3. 왜냐하면 HttpServlet에는 몇가지 규칙과 메서드를 따라야 하므로, 이것을 상속받으면 특정 기술에 종속되는 것이기 때문입니다.
4. 서비스 클래스나 레파지토리 클래스에서 DI를 할 때 결합도를 낮추고 응집도를 높여 코드의 재사용성을 높이기 위해 인터페이스를 구현합니다.
그 인터페이스를 PSA라고 합니다.
5. PSA는 자바언어스펙에 포함되지 않습니다.
POJO는 자바언어스펙 외의 기술에 종속되면 안됩니다.
즉 PSA를 구현하면 엄밀히는 POJO라고 할 수 없습니다.

따라서 서비스 클래스의 객체, 레파지토리 클래스의 객체, IOC 컨테이너의 자바빈들은 엄밀히는 POJO가 아닙니다.
6. 그러나, POJO의 목적인 결합도를 낮추고 응집도를 높이고 재사용성을 높이기 위해 PSA를 구현한 것이므로, 스프링의 서비스나 레파지토리 클래스, 그리고 ioc 컨테이너에 선언된 자바빈들도 POJO에 가깝다고 볼 수 있습니다.
7. 어노테이션이 아닌 XML 방식을 사용한다면 더 POJO에 가깝게 만들 수 있습니다.

라고 이해했습니다.

David님의 프로필

David

2023.06.28

PSA는 Spring Framework가 특정 기술, 라이브러리, 또는 독점 API에 대한 의존성을 최소화하려는 구조적 설계 패턴을 가리킵니다. 따라서, 해당 설계 패턴대로 작성했다고 하여서 POJO가 아닌 것은 아닙니다.

PSA의 주요 개념은 애플리케이션이 의존하는 서비스, 예를 들어 데이터베이스 접근, 메시징, 트랜잭션, 캐싱 등의 특정 저수준 세부 사항에 비즈니스 로직이 강하게 결합되어서는 안된다는 것입니다. 대신, 비즈니스 로직은 인터페이스나 추상 클래스로 제공되는 고수준, 기술 중립적인 추상화를 통해 이러한 서비스와 상호 작용해야 합니다.

지금 당장 이해가 되지 않더라도 강의를 쭉 들으시면서 코드를 작성해 보시면 POJO, PSA 등과 같은 개념에 대해 더욱 잘 이해하실 수 있을 것 같습니다. 이론도 중요하지만 코드를 작성해 보면서 이론의 내용이 깨달아 지는 부분도 있기 때문입니다.

선생님 가르쳐주셔서 감사합니다
선생님 말씀처럼 코드를 작성해보면서 이론을 더 이해해보려고 하겠습니다

선생님 하나만 더 질문드리고 싶은데 받아주시면 정말 감사하겠습니다.
서비스 클래스가 구현한 인터페이스도 PSA로 봐도 되는지 질문드리고 싶습니다.

Controller{
@Autowired

Iservice service

}

ServiceImpl implements Iservice{

}
일 때 Iservice도 PSA로 봐도 되는지 질문드리고 싶습니다.

왜냐하면 컨트롤러 클래스에 의존성 주입을 할 때 서비스클 래스와의 결합도를 낮추기 위해서 서비스클래스가 인터페이스를 구현하게 하고, 컨트롤러 클래스에는 서비스의 인터페이스 변수만 선언하기 때문입니다.

그래서 서비스 클래스의 인터페이스도 PSA라는 생각이 들었습니다.

혹시 이렇게 생각해도 맞는지 봐주시면 감사하겠습니다
스프링프레임워크에서 클래스 간의 결합도를 낮추기 위한 인터페이스는 전부 PSA 로 봐도 되는지 질문드리고 싶습니다.
긴 질문을 받아주셔서 감사합니다.

David님의 프로필

David

2023.06.28

네, 맞습니다.

PSA를 구현하기 위해 사용되는 일반적인 방법이 인터페이스를 사용하는 것입니다.

선생님 덕분에 명쾌히 이해가 되었습니다.
정말 감사합니다!