230116 ~ 230119 TIL

이지섭·2023년 1월 19일

오늘의 공부

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와 블랙리스트 (로그아웃 구현)
  • 위염 조심하자...
profile
Stop thinking. Just do it.

0개의 댓글