10/09 TIL

스프링에서 DI (의존성 주입) 를 사용하는 이유

스프링은 객체지향프로그래밍을 극대화 하기 위해서 만들어진 프레임워크이다. 객체지향설계 5원칙 중 SRP,DIP 원칙이 있으며 각각 SRP - 객체는 단 하나의 책임만 가져야 한다는 원칙 DIP - 추상화에 의존해야하며, 구체화에 의존하면 안된다. 만약 한 클래스가 다른 클래스를 의존한다면 DIP 원칙을 어기게 되며, 이를 해결하기 위해 인터페이스를 의존하도록 한다, 그럼 실질적인 객체는 누가 넣어줄 수 있을까? 명확한 역할을 가지고 잇는 controller, service계층에서 객체를 넣어준다면 이것도 "단 하나의 책임만 가져야한다"라는 SRP원칙을 위반하게 된다. 즉 객체만 넣어주는 전문적인 class가 필요하며 이를 DI, 의존성 주입이라고 한다. 즉 DI는 객체지향설계 5원칙 중, SRP과 DIP 원칙을 지키기 위해서 사용하고 있다.

스프링 프레임워크의 특징과 장점

가장 성공적인 경량 프레임워크 그당시 존재하던 복잡한 엔터프라이즈급 프레임워크들과는 다르게 Java의 클래스와 인터페이스를 이용하는 구조이기 때문에 진입장벽이 낮고 가벼웠다. 웹 영역, 데이터베이스 영역에 국한된 다른 프레임워크들과 다르게 한 분야 집중하지 않고 전체를 설계하는 용도로 사용되었다 다른 프레임워크들을 끌어다 쓸 수 있는 포용성이 있었다. POJO 기반의 구성 스프링 내부의 객체관의 관계를 구성할 때 별도의 API를 쓰지 않고 POJO(Plain Old Java Object)의 구성만으로도 가능하도록 제작되었다. 쉽게 말해, 평소에 쓰던 자바 코드를 이용해서 객체를 구성하는 방식을 스프링에서도 그대로 쓸 수 있다. POJO의 장점은 코드를 개발할 때 특정한 라이브러리나 컨테이너 기술에 종속적이지 않기 때문이다. AOP의 지원 개발자에게 있어서 좋은 개발환경은 반복적인 코드를 제거할 수 있고, 비즈니스 로직에만 집중할 수 있는 환경이다. 특히, 보안, 로그, 트랜잭션 같이 비즈니스 로직은 아니지만 필수적으로 처리를 해야하는 부분을 횡단관심사(cross-concern)이라고 부르는데 스프링은 이런 횡단관심사를 AOP를 통해 모듈로 분리하여 제작하는 것이 가능해졌다.

개발자 테스트코드 작성 시 장/단점과 테스트 종류별 특징 (단위테스트,통합테스트.E2E테스트)

장점 - 자신의 코드 품질을 증명해 볼 수 있다. 테스트가 된 코드라면 심리적 안정감을 가질수 있으며 좋은설계를 유도해줄 수 있다. 결함을 쉽게 찾을수 있고 유지관리 시간을 절약할 수 있다. 단계별로 진행을 하기 때문에 현재 내가 어떤 기능을 개발하고 어디까지 와있는지 살펴볼 수 있다. 리펙토링을 과감하게 시도할 수 있다 추가구현이 용이하다. 단점 - 시간소요가 많이 발생할 수 있다. 하나의 피쳐를 만드는데 시간이 많이걸린다. 코드의 품질보다 빠른 결과물을 원한다면 도입이 어려울 수 있다.즉 코드의 생산성이 떨어지는 면이 있다. 많은연습이 필요하다. 단기간에 잘 작성할 수 있는건 어려운 일이다. 단위테스트 - UnitTest는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확 하게 작동하는지 검증하는 절차이다 즉, 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 절차를 말한다.매우 간단하고 명확하며 빠르게 실행된다는 특징이 있으며, 하나의 함수에 대해 하나 이상의 테스트가 존재할 수 있고 각각의 조건에 대한 유효 성을 검증합니다. 이렇게 작성된 단위 테스트가 많을수록 해당 로직에 대한 신뢰도가 높아질 수 있고 작게 쪼개진 단위테스트는 해당 로직이 어떤 역할을 하는지 쉽게 파 악할 수 있습니다. 통합테스트 - Integration Test는 서로 다른 모듈 혹은 클래스 간 상호작용의 유효성을 검사 하는 테스트 입니다. 이것이 필요한 이유는 각각의 단위 테스트가 검증되었다 하더라 도, 모듈 간 인터페이스 및 데이터의 흐름이 의도한 대로 제대로 동작하지 않는 경우 도 있기 때문에 조금 더 넓은 범위에서 추가적인 테스트가 필요합니다.또한 각 모듈 에 대한 설정 또는 테스트를 하기 위해 사전 조건이 필요한 경우도 있기 때문에 단 위 테스트에 보다 테스트 코드를 작성하기 복잡하지만 단위테스트보다 더 넓은 범위 의 종속성까지 테스트함으로써 단위테스트보다 좀 더 유의미한 테스트가 되는 경우도 많습니다. E2E테스트 -종단 간 테스트는 처음부터 끝까지 애플리게이션 흐름을 테스트하는 소프트웨어 테스트 방법입니다. 이의 목적은 실제 사용자 시나리오를 시뮬레이션하고 테스트중인 시스템과 해당 구성요소의 통합 및 데이터 무결성을 검증하는 것입니다. 즉 사용자에 게 직접 노출되는 부분을 점검한다고 생각하면 좋을것 같습니다.

ORM-JPA-Spring Data JPA 구분설명

ORM 1. Object-Relational Mapping Object: “객체“지향 언어 (자바, 파이썬) Relational: “관계형” 데이터베이스 (H2, MySQL )= 객체관계매핑 2. 데이터베이스와 객체 지향 프로그래밍 언어 간의 호환되지 않는 데이터를 변환하는 프로그래밍 기법이다 3. 웹 서버 개발 언어(Java, Python, Javascript 등) 와 관계형 데이터베이스 언어 (SQL)의 목적 및 사용방법이 다름 4.ORM 없이도 충분히 웹 서버 개발 가능하지만 백엔드 개발자가 비즈니스 로직 개발보다 SQL 작성에 더 많은 노력을 들이게 돠고SQL 작성이 단순하고 반복적인데, 실수하기는 쉽다. (하지만 백엔드 개발자는 DB 에 대해 잘 알고 있어야 함) Java Persistence API 1.자바 ORM 기술에 대한 표준 명세 2.자바를 사용하는 응용프로그램에서 관계형 데이터베이스의 관리를 표현하는 자바 API이다. Spring Data JPA 1. JPA 를 편리하게 사용하기 위해, 스프링에서 JPA 를 Wrapping한것이다. 2. 즉 OPA를 표준화한 JPA를 더욱 표준화한 것이라고 보면 된다. 3. 스프링 개발자들이 JPA 를 사용할 때 필수적으로 생성해야 하나, 예상 가능하고 반복적인 코드들을 Spring Data JPA 가 대신 작성하고Repostiory 인터페이스만 작성하면, 필요한 구현은 스프링이 대신 알아서 해준다.

- 회원가입, 로그인, 로그인 유지 4개의 모듈

(Client, Server, Session, DB) 로 나누어 정리

1.회원가입

2.로그인, 로그인 유지

스프링MVC 동작방식

1.클라이언트가 서버에 요청하면 DispatcherServlet이 먼저 요청을 받는다.
2.DispatcherServlet은 요청된 URL을 HandlerMapping 객체에 넘기고, 호출해야 할 Controller메소드 정보를 얻는다.
3.DispatcherServlet이 HandelrAdapter객체를 가져온다.
4. HandlerAdapter 객체의 메소드를 실행한다.
5. Controller 객체는 비즈니스 로직을 처리하고, 그 결과를 바탕으로 뷰(ex. JSP)에 전달할 객체를
Model 객체에 저장한다. DispatcherServlet에게 view name을 리턴한다.
6. DispatcherServlet은 view name을 View Resolver에게 전달하여 View 객체를 얻는다.
7. DispatcherServlet은 View 객체에 화면 표시를 의뢰한다.
8. View 객체는 해당하는 뷰(ex. JSP, Thymeleaf)를 호출하며, 뷰는 Model 객체에서 화면 표시에 필요한 객체를 가져와 화면 표시를 처리한다

JPA가 업데이트를 처리하는 방법

JPA는 "영속성 컨텍스트"라는 엔티티를 영구 저장하는 환경이 있다.
이 속에 1차 캐시가 존재하며 DB에서 불러온 데이터를 이곳에 저장한다.
이 곳에 저장을 하면 컨텍스트는 이 데이터의 정보를 스캔하고 저장한다.
이 엔티티의 데이터가 변경이 되고 트랜잭션이 되는 순간 내부적으로 "flush()" 함수가 호출된다.
이 때 엔티티의 현재 데이터와 초기에 스캔한 엔티티 데이터를 비교하여 데이터 변경 사항이 있다면
변경 사항에 맞는 update sql를 만들고 sql 저장소에 저장,
커밋이 되면 flush()가 호출된 후 db에 update 쿼리가 날라간다.