230116 ~ 230119 TIL

오늘의 공부

merge의 종류

• 3way merge
  • 기준과 신규 각각 커밋이 있고, 둘을 합침
  • 가장 기본이지만, 너무 많이 하면 브랜치가 복잡해짐
  • main 브랜치 내역만 보려는데 다른 브랜치 로그까지 다 나옴
• fast-forward merge
  • 기준에는 커밋이 없고, 신규에만 커밋이 있음
  • 신규가 그냥 다시 기준이 되면서 합쳐짐
    • 브랜치 한줄로 관리 가능
  • git merge —no-ff 하면 강제로 3way merge 됨
• rebase and merge
  • 신규에서 개발중이었는데 기준에 커밋이 생긴 경우
  • 신규 브랜치를 떼어서 기준 브랜치 최신 커밋에 붙인다
    • 단점 : conflict 많이 나서 귀찮다
• squash and merge
  • 여러개의 자잘한 커밋들을 하나로 합쳐서 merge
• merge 해도 branch는 남아있다
  • 목적을 다 한 branch는 삭제

git 팁

• git push -u 원격저장소주소 올릴로컬브랜치명
  • -u는 주소 기억해두라는 의미이므로, 한번 쓴 이후부터는 git push만 해도 됨
• Collaborators 등록해놔야 git push 가능하다
  • 내가 뭘 하고있었는데 누군가 먼저 push해서 상태가 변하면 나는 push가 불가능해진다
  • git pull을 하면 된다 (fetch + merge) = merge
    • conflict 발생 가능
  • 사람이 많아질 수록 이런 방식은 꼬이기 마련
    • 그래서 원격저장소에서 branch 따서 협업하는 것
• 깃 원격 브랜치 확인
  • git branch
  • git branch -r
  • git branch -a

스프링에서의 MVC?

• Model = servie + entity + 데이터 파트
  • 데이터를 다룬다
• View = Templates 폴더
  • Model을 시각적으로 볼 수 있게 해준다
• Controller
  • Model과 View를 연결한다
• 역할에 따른 설계
  • 유지보수 비용을 낮춘다
• ModelAndView의 Model은 다른 개념이다
• 다양한 MVC 웹 프레임워크들
  • Java의 Spring
  • PHP의 Laravel
  • Python의 Django (MTV)
  • Ruby의 Ruby on Rails (일본에서 많이 쓰임)
  • Scala의 Play
  • Typescript의 Angular (FE)
  • C#의 .NET Core

MVC를 지키면서 코딩하는 방법 5가지

• Model은 View와 Controller에 의존하면 안된다
• View는 Model에만 의존한다 (View 내부에 Model의 코드만 있을 수 있다)
• Controller는 Model과 View에 의존해도 된다
• View가 Model로부터 데이터를 받을 때는,
  사용자마다 다르게 보여줘야 하는 데이터만 받아야 한다
• View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다

Dto는 용도별로 다 분리하자

• 만능requestDto 사용하면 나중에 일부 수정할 때 난감해질 수도

페이징

• 수많은 결과를 그대로 보내면 부하가 많이 걸린다
• 그래서 탄생한게 페이징으로 잘라보내는 기능

ManyToMany는 진짜 꼭 필요한 경우에만

• 개발자도 모르는 테이블이 생성될 수도 있다
  • 중간테이블은 alter가 불가능하다
  • mapping 정보만 저장된다
  • 예상치 못한, 불필요한 쿼리가 JPA에서 자동으로 나갈 수 있다
• 직접 중간 테이블을 만들어서 ManyToOne + OneToMany로 해결
• 튜터님도 잘 안쓰심

IoC 제어의 역전

• 일반적으로는 사용자가 자신이 필요한 객체를 그 때 생성해서 코드를 작성한다
• 제어의 역전 : 용도에 맞게 미리 만들어진(만들어질) 객체를 가져다 코드를 작성한다
  • bean : 스프링이 관리하는 객체
  • IoC 컨테이너 : 빈을 모아둔 공간
  • DI : 의존성 주입 = 조립
• bean 자동등록 방법
  • 클래스 위에 @Component
  • 서버 실행시에 IoC에 bean 저장 (클래스 옆에 콩알표시가 뜬다)
  • 이때 bean 객체명 : 클래스의 앞글자만 소문자로 변경
    • 자동등록 조건
      • @ComponentScan에 설정해 준 basePackages 위치와 그 하위 패키지들
      • @SpringBootApplication에 @ComponentScan 기본값 설정되어있다
        • @ComponentScan이 걸려있는 패키지의 하위 패키지들에 있는
          @Component가 달린 클래스들을 찾아서
          bean 등록해서 IoC 컨테이너에 담아두겠다는 뜻
• 개발자가 수동등록 하는 방법도 있다
  • config 패키지에서 클래스를 만들고 @Configuration과 @Bean 사용
  • 마찬가지로 서버 실행시에 등록된다
• DI 방법
  • @Autowired
    • 주입하려는 변수 위 또는 해당 변수를 사용할 함수 위에 단다
  • @Autowired 적용조건
    • 스프링 IoC 컨테이너에 의해 관리되는 클래스만 가능
    • 생략조건
      • 생성자 선언이 여러개(오버로딩)면 다 @Autowired 달아줘야 함
      • 생성자 선언이 하나만 있으면 생략 가능
      • Lombok의 @RequiredArgsConstructor 사용하면 final 선언 만으로도 작성 가능
  • 빈을 수동으로 가져오는 방법
    • ApplicationContext // 이런 방법도 있구나~

      ProductRepository productRepository = (ProductRepository) context.getBean("productRepository");
      this.productRepository = productRepository;

• @Controller, @RestController, @Service, @Repository 등등
  • 내부에 모두 @Component가 들어있다
• interface에 JpaRepository 상속만 받아도 빈 등록 됨
  • JpaRepository<”@Entity 클래스”, “@Id 데이터 타입”>을 상속받는 interface로 선언

문제와 시도

팀 프로젝트에 swagger 적용하려는데 잘 안된다...

• 과정 정리해두고 다음 TIL에 추가예정

메모

• OneToMany, ManyToOne 대칭으로 쓸 필요는 없다?
• ResponseEntity
  • 프론트단의 편의를 위해?
• Spring은 src/main/resources/static 폴더의 index.html 을 자동으로 인식하여
  메인 페이지로 띄워준다 (welcome page)
• Redis와 블랙리스트 (로그아웃 구현)
• 위염 조심하자...