인프런 커뮤니티 질문&답변
작성자 없음
작성자 정보가 삭제된 글입니다.
POJO로 개발 후 스프링으로 전환, 이후 JPA 전환하는 이유
작성
·
1.1K
4
POJO로 개발 후 스프링으로 전환, 이후 JPA 전환하는 이유가 있나요??
처음부터 JPA로 만들면 안되는지 궁금합니다
답변 2
4
이중석
지식공유자
안녕하세요 마운틴 님!
POJO로 개발한 후 스프링으로 전환하고 마지막에 JPA로 전환하는 이유는 주로 설계 및 개발 과정에서의 효율성과 유연성 때문입니다. 처음부터 JPA로 개발하는 것도 가능하지만, 이렇게 접근할 경우 다음과 같은 단점이 있습니다.
데이터 중심의 설계: JPA를 처음부터 사용하게 되면, 데이터 중심의 설계가 나오기 쉽습니다. 이로 인해 객체지향적인 설계 원칙이 무시되거나 희생될 수 있습니다. 반면, POJO를 먼저 사용하면 객체지향적인 설계 원칙에 충실한 코드를 작성할 수 있으며, 이후에 JPA로 전환하면서 객체와 데이터베이스 사이의 연동을 수월하게 할 수 있습니다.
개발 시간: JPA를 처음부터 사용하면, 초기 개발 시간이 상대적으로 더 많이 소요됩니다. 반면에 POJO로 먼저 개발하면, 기능 구현에 집중하여 빠르게 개발할 수 있으며, 이후 스프링 및 JPA로 전환하면서 필요한 부분만 점진적으로 수정해 나갈 수 있습니다.
따라서, POJO로 개발한 후 스프링과 JPA로 전환하는 접근 방식은 객체지향적인 설계 원칙을 준수하면서도 개발 시간을 줄이고 유연한 코드 작성이 가능한 방법입니다.
2
개인적으로 테스트 코드를 작성할 때, ApiTest와 Domain에 대한 단위 테스트만 남겨두는 편입니다.
아래와 같은 이유에서 그렇게 작성합니다!
중복성 제거: POJO, SpringBootTest, ApiTest 세 가지 테스트를 모두 남겨두게 되면, 테스트 코드 간에 중복성이 발생할 수 있습니다. 이는 코드의 유지보수를 어렵게 만들기 때문에, 중복을 최소화하고자 ApiTest와 Domain에 대한 단위 테스트만 남겨두는 편입니다.
요구사항 변경에 대한 유연성: 요구사항이 변경되었을 때, 세 가지 테스트 모두를 수정해야 하는 경우가 발생할 수 있습니다. 이럴 경우 테스트 코드가 깨지기 쉽고, 수정 작업이 번거로워질 수 있습니다. 따라서, ApiTest와 Domain에 대한 단위 테스트만 남겨두어 요구사항 변경에 대한 유연성을 확보하는 것이 좋습니다.
ApiTest와 Domain에 대한 단위 테스트만 남겨두고 나머지 테스트 케이스는 제거하는 것이 테스트 코드의 중복성을 줄이고, 요구사항 변경에 대한 유연성을 확보하는 데 도움이 되는거같습니다!