그리고 작업을 한 내용은 프로모션 검증하는 내용을 위챗 내부에 추가해야 해서 프로모션 백엔드를 호출하는 post method를 추가해야 했기에, 프로모션 백엔드를 위챗에 추가된 도메인 내부에 배포해야 했다!

단순히 ec2에 배포하면 되겠거니 하고, docker-compose로 배포한 후 postman으로 헬스체크를 해보니 Error: connect ECONNREFUSED 71.xxx.xx.x:8080 라는 응답을 받았다. 근데 내가 배포한 ec2 ip는 71로 시작하지 않는걸????????????????

AWS에 접속해서 확인하니, 로드밸런서와 타겟 그룹이 보인다🙃🙃🙃

로드 밸런서 (ALB - Application Load Balancer)

로드 밸런서는 여러 서버(인스턴스) 간에 네트워크 트래픽을 자동으로 분산하여 서버의 부하를 분산하고 애플리케이션의 가용성과 성능을 높이는 장치 또는 서비스입니다. 주로 사용자의 요청을 서버 여러 대에 고르게 분산해 주며, 단일 서버에 과부하가 걸리는 상황을 방지해줍니다.

역할

• 트래픽 분산: 여러 서버로 요청을 분산하여 각 서버의 부하를 줄이고 시스템의 안정성을 유지합니다.
• 고가용성 제공: 서버 중 하나가 고장 나더라도 다른 서버가 트래픽을 처리하여 서비스가 중단되지 않도록 합니다. 장애 감지 및 헬스 체크: 로드 밸런서는 각 서버의 상태를 정기적으로 확인(헬스 체크)하여, 비정상적인 서버로는 트래픽을 보내지 않습니다.
• 보안 강화: HTTPS를 통해 암호화된 트래픽을 처리하여 클라이언트와 서버 간의 보안을 강화할 수 있습니다.

로드 밸런서의 종류

AWS에서는 여러 유형의 로드 밸런서를 제공합니다:

1. Application Load Balancer (ALB)

HTTP/HTTPS 트래픽을 분산하는 데 최적화되어 있습니다. 경로 기반 또는 호스트 기반 라우팅이 가능하며, URL의 경로나 도메인 이름에 따라 트래픽을 특정 서버로 라우팅할 수 있습니다. 주로 웹 애플리케이션이나 API 트래픽을 처리할 때 사용됩니다.

2. Network Load Balancer (NLB)

TCP/UDP 트래픽을 빠르게 처리하며, 초당 수백만 개의 요청을 처리할 수 있는 고성능 로드 밸런서입니다. 주로 초저지연과 고성능이 필요한 트래픽에 적합합니다.

3. Classic Load Balancer (CLB)

과거에 사용되던 기본적인 로드 밸런서입니다. 현재는 새로운 프로젝트에 ALB 또는 NLB가 권장됩니다. 애플리케이션 및 네트워크 계층에서의 간단한 로드 밸런싱이 가능합니다.

로드 밸런서의 구성 요소

1. 리스너 (Listener)

리스너는 로드 밸런서가 요청을 수신하는 프로토콜과 포트를 정의합니다. 예를 들어, HTTP:80, HTTPS:443과 같이 특정 포트와 프로토콜을 설정하여 클라이언트의 요청을 받아들입니다.

2. 대상 그룹 (Target Group)

로드 밸런서가 트래픽을 전달할 서버 또는 서비스 그룹을 정의합니다. 대상 그룹에는 EC2 인스턴스, Lambda 함수, 컨테이너 등 다양한 대상이 포함될 수 있습니다. 헬스 체크 설정을 통해 각 서버의 상태를 모니터링하고, 비정상 서버로는 트래픽을 전달하지 않도록 합니다.

3. 헬스 체크 (Health Check)

로드 밸런서는 대상 서버의 상태를 주기적으로 확인하여, 정상적인 서버에만 트래픽을 분산합니다. 헬스 체크가 실패하면 해당 서버는 Unhealthy 상태로 표시되어 트래픽이 전달되지 않습니다.

로드 밸런서를 설정하려면?

1. 로드 밸런서 생성: AWS Management Console에서 Application, Network, 또는 Classic Load Balancer를 생성합니다.

2. 리스너 설정: 로드 밸런서가 사용할 프로토콜과 포트를 지정하고 리스너를 설정합니다. 대상 그룹 생성 및 등록: 트래픽을 분산할 서버(대상)를 지정하여 대상 그룹을 생성하고 로드 밸런서와 연결합니다.

3. 헬스 체크 설정: 서버가 정상 상태인지 확인하기 위해 헬스 체크 경로와 주기를 설정합니다.

4. 예시: ALB로 웹 애플리케이션 트래픽 분산

   클라이언트가 ALB의 도메인(예: example.com)으로 요청을 보냅니다.
   HTTP:80 리스너가 요청을 수신하고, HTTPS로 리다이렉션합니다.
   HTTPS:443 리스너가 요청을 처리하며, /api/*로 들어오는 트래픽은 Spring Boot 서비스로, 
   나머지 트래픽은 Tomcat 서버로 라우팅하는 규칙에 따라 요청을 분배합니다.
   로드 밸런서의 헬스 체크가 서버 상태를 주기적으로 확인하여, 
   Healthy 상태인 서버에만 트래픽을 전달합니다.

   리스너

   로드 밸런서에서 리스너(Listener)는 클라이언트 요청을 수신하고, 이를 설정된 대상 그룹(Target Group)으로 전달하는 역할을 하는 구성 요소입니다. 리스너는 특정 프로토콜과 포트에 대한 트래픽을 관리하며, 이를 통해 로드 밸런서가 어떻게 요청을 처리할지 결정합니다.

역할

1. 요청 수신: 리스너는 지정된 프로토콜(예: HTTP, HTTPS)과 포트(예: 80, 443)에서 들어오는 요청을 수신합니다.
2. 규칙 평가: 리스너에는 여러 개의 규칙을 설정할 수 있습니다. 각 규칙은 URL 경로, 요청 헤더, IP 주소 등 특정 조건에 따라 요청을 필터링하여 각기 다른 대상 그룹(Target Group)으로 트래픽을 라우팅합니다.
3. 대상 그룹으로 트래픽 포워딩: 규칙에 따라 요청을 특정 대상 그룹으로 포워딩합니다. 대상 그룹은 로드 밸런서가 분산해야 할 실제 서버(예: EC2 인스턴스) 또는 컨테이너 그룹입니다.
4. SSL 종료: HTTPS 리스너의 경우, SSL 인증서를 사용하여 SSL/TLS 연결을 종료하고 클라이언트와 보안 통신을 설정합니다.

리스너 구성 요소

• 프로토콜: 리스너가 수신할 요청의 프로토콜 (예: HTTP 또는 HTTPS).
• 포트: 리스너가 요청을 수신할 포트 (예: 80, 443).
• 규칙: 트래픽 라우팅 조건을 설정할 수 있는 규칙입니다. 예를 들어, /api/*로 시작하는 모든 요청을 특정 대상 그룹으로 보내도록 규칙을 설정할 수 있습니다.
• 대상 그룹: 리스너가 요청을 전달할 대상 그룹을 지정합니다.

  리스너 설정 방법

  1. 로드 밸런서 생성 시 리스너 설정

• 로드 밸런서를 처음 생성할 때 리스너를 설정할 수 있습니다. 이때, 기본 프로토콜과 포트를 지정합니다.

2. 기존 로드 밸런서에 리스너 추가

• AWS Management Console에서 로드 밸런서의 Listeners 탭에서 리스너를 추가할 수 있습니다.

  3. 필요한 구성 설정

• 프로토콜 및 포트 설정: 트래픽을 처리할 프로토콜 (HTTP, HTTPS)과 포트를 설정합니다.
• 규칙 추가: 경로 기반 라우팅을 설정하려면 Add rule 기능을 사용하여 요청 경로에 따라 트래픽을 라우팅하는 규칙을 추가합니다.
• SSL 인증서 (HTTPS의 경우): HTTPS 리스너를 사용할 때는 SSL 인증서를 설정해야 합니다. 이 설정을 통해 클라이언트와 로드 밸런서 간의 트래픽을 암호화할 수 있습니다.

타겟 그룹

타겟 그룹(Target Group)은 로드 밸런서가 트래픽을 전달하는 서버 그룹입니다. 로드 밸런서는 타겟 그룹을 통해 여러 서버(예: EC2 인스턴스)로 트래픽을 분산하고, 헬스 체크를 통해 서버 상태를 관리합니다. 각 타겟 그룹은 로드 밸런서가 요청을 분산할 서버나 서비스들을 정의하며, 특정 조건에 맞춰 선택적으로 요청을 전달할 수 있습니다.

타겟 그룹의 역할과 기능

1. 트래픽 분산 대상 지정

• 타겟 그룹은 로드 밸런서가 트래픽을 보낼 서버(인스턴스, 컨테이너, IP 등)를 지정합니다.
• 각 타겟 그룹에는 하나 이상의 서버가 포함될 수 있으며, 로드 밸런서는 타겟 그룹의 서버들로 요청을 자동으로 분산합니다.

2. 헬스 체크(Health Check) 관리

• 타겟 그룹 내 서버의 상태를 주기적으로 확인하여, 정상(Healthy) 상태가 아닌 서버로는 트래픽을 보내지 않습니다.
• 헬스 체크 설정(경로, 주기, 응답 시간)을 통해 서버가 정상인지 여부를 판단합니다.

3. 라우팅 규칙과 연계

• 로드 밸런서의 리스너에서 조건(경로, 헤더, 도메인 등)에 따라 요청을 특정 타겟 그룹으로 라우팅할 수 있습니다. 예를 들어, /api/* 경로는 API 서버로, /web/* 경로는 웹 서버로 분산할 수 있습니다.

4. 특정 애플리케이션 설정

• 타겟 그룹을 통해 로드 밸런서가 다양한 서비스(예: 마이크로서비스 아키텍처에서 API 서버, 웹 서버 등)로 요청을 분산할 수 있습니다. 각 서비스마다 별도의 타겟 그룹을 생성하고 라우팅 규칙을 설정해주면 됩니다.

타겟 그룹의 구성 요소

1. 타겟(Target)

• 트래픽을 전달할 서버나 인스턴스입니다. 타겟은 EC2 인스턴스, Lambda 함수, IP 주소, 또는 ECS 컨테이너 등으로 지정할 수 있습니다.

2. 타겟 그룹 유형(Target Type)

• Instance: EC2 인스턴스를 타겟으로 지정.
• IP: 특정 IP 주소(프라이빗 IP 또는 퍼블릭 IP)를 타겟으로 지정.
• Lambda: Lambda 함수를 타겟으로 지정하여, 요청을 Lambda 함수로 분산.

3. 포트와 프로토콜

• 타겟 그룹 내의 타겟이 요청을 수신할 포트와 프로토콜을 정의합니다. 예를 들어, HTTP 프로토콜과 포트 8080을 사용하여 웹 서버로 요청을 전달할 수 있습니다.

4.헬스 체크 설정

• 헬스 체크 프로토콜 및 경로: 서버 상태를 확인하기 위해 HTTP, HTTPS와 같은 프로토콜과 경로(예: /health 또는 /status)를 지정합니다.
• 헬스 체크 주기 및 타임아웃: 헬스 체크 요청을 보내는 주기와 응답 대기 시간을 설정합니다. 서버가 헬스 체크를 통과하지 못하면 Unhealthy로 표시됩니다.
• 정상/비정상 임계값: 특정 횟수 이상의 헬스 체크를 통과해야 Healthy 상태로 표시되며, 연속 실패 시 Unhealthy로 전환됩니다.

타겟 그룹의 작동 예시

1. HTTP 요청 분산

• ALB가 HTTP 요청을 수신한 후, 요청 경로에 따라 특정 타겟 그룹으로 분산합니다.

• 예를 들어, /api/* 경로는 타겟 그룹 API-Backend로, /web/* 경로는 타겟 그룹 Web-Frontend로 라우팅할 수 있습니다.

  2. 헬스 체크에 따른 트래픽 분산

• 타겟 그룹은 각 타겟의 헬스 체크를 통해 상태를 주기적으로 확인하며, Healthy 상태의 타겟에게만 트래픽을 전달합니다.

• 만약 서버가 Unhealthy 상태로 표시되면 로드 밸런서는 자동으로 다른 타겟에 트래픽을 전달합니다.

  타겟 그룹 설정 방법

  1. 로드 밸런서와 연결할 타겟 그룹 생성

• AWS Management Console에서 EC2 서비스 > Target Groups 메뉴에서 새 타겟 그룹을 생성합니다.

• 타겟 유형, 프로토콜 및 포트 등을 설정합니다.

2. 타겟 등록

• 트래픽을 수신할 타겟을 선택하여 타겟 그룹에 등록합니다. 예를 들어, EC2 인스턴스, IP 주소 또는 Lambda 함수를 추가할 수 있습니다.

3. 헬스 체크 설정

• 헬스 체크 경로, 프로토콜, 주기, 타임아웃 등의 설정을 지정하여 서버 상태를 모니터링할 수 있습니다.

4. 로드 밸런서에 타겟 그룹 연결

• 로드 밸런서의 리스너 규칙에 따라 트래픽이 특정 타겟 그룹으로 전달되도록 설정합니다. 예를 들어, HTTPS 리스너에서 /api/* 요청이 API 서버 타겟 그룹으로 라우팅되도록 규칙을 추가할 수 있습니다.

실제 구성 예시

클라이언트 요청
    ↓
도메인 (wechat.xxx.cn)
    ↓
ALB (HTTPS:443)
    ↓
리스너 규칙에 따라 분기
    ├── /api/promotion/* → WECHAT-PROMOTION-8080-BACKEND (Spring Boot)
    └── 그 외 → WECHAT-8090-TOMCAT (Tomcat)

보안 그룹

• ALB의 보안 그룹

  • 인바운드: HTTPS(443) 허용
  • 아웃바운드: 타겟 그룹의 포트(8080, 8090) 허용

• EC2의 보안 그룹

  • 인바운드: ALB로부터의 트래픽 허용
  • 포트: 애플리케이션 포트(8080, 8090)

헬스 체크

• 각 타겟 그룹별로 설정
• 주기적으로 지정된 엔드포인트로 요청
• 성공/실패에 따라 타겟의 상태 결정
• 비정상 타겟은 자동으로 트래픽에서 제외

실제 서버 적용

• 위의 도식화처럼, 로드밸런서에는 2개의 리스너가 존재
• HTTP:80은 HTTPS:443으로 리다이렉트해주는 기능을 하는 리스너
• HTTPS:443 리스너는 다시 2개의 규칙이 존재
  • 기존 규칙은 52.xx.xxx.x:8090로 포워딩되고 있음
  • 여기에 새로운 규칙을 추가하여, /api/promotion/* 의 path 패턴의 경우 52.xx.xxx.x:8080 으로 포워딩 되도록 설정 ( 우선순위를 10으로 둬서 default보다 우선적으로 처리)

로컬호스트를 https를 붙여서 접속할 방법이 없을까 찾아보다가, localtunnel 및 다른 방법도 시도했지만, ngrok이 가장 쉬운 방법이다!

ngrok은 로컬 개발 환경의 서버를 안전하게 인터넷에 노출시키는 터널링 도구다. ngrok은 로컬호스트에서 실행 중인 웹 서버에 대해 보안 터널을 생성하고, 공개적으로 접근 가능한 URL을 제공한다. 이를 통해 개발자는 방화벽 제한이나 NAT(Network Address Translation) 문제 없이 외부에서 로컬 서버에 접근할 수 있게 되어, 웹훅 테스트, 모바일 앱 개발, 원격 데모 등 다양한 개발 시나리오를 용이하게 한다.

사용방법

1. ngrok 사이트에 접속하여, os에 맞는 다운로드를 실행한다.
2. 다운로드 받은 ngrok 프로그램을 실행한다.
3. 특정 포트를 터널링한다.

    ngrok http 80

2개 포트는 안돼?

공식 사이트에서는 분명!! pricing에 애매모호하지만, 2개의 포트에 대해 터널링이 가능하다고 하지만, 프로그램을 2개 실행해서 명령어를 입력하는 방법도, 한 번에 2개의 명령어를 입력하는 방법도 되지 않는다. 그치만 나는 총 3개의 프로젝트를 함께 변경중으로, 위챗에서는 2개의 프로젝트를 로컬호스트로 붙어야 한다! 약 3일간의 삽질을 하다가(3일 내내 한 것은 아니고 시간이 날 때마다,,,) 방법을 찾았다. 그건 바로 ngrok의 실행 파일 내부에 포워딩할 포트를 지정하고, 실행하는 것!

무료로 2개 포트를 포워딩하는 방법

1. ngrok 프로그램을 실행한다.
2. ngrok config edit 명령어를 입력한다. 설정 파일을 수정하는 명령어로, 해당 파일은 C:\Users\AppData\Local\ngrok 경로의 ngrok.yml이다.
3. ngrok.yml 파일 내부에 터널링할 포트 정보를 입력한다. authtoken값도 같이 입력해두면 편리하다.

   version: "2"
   authtoken: 내 authToken값
   

tunnels: tunnel1: addr: 8082 proto: http tunnel2: addr: 8080 proto: http

4. ngrok 프로그램에 설정 파일을 실행한다는 명령어 입력

ngrok start --all

무료로 사용하면 ngrok가 꺼질 때마다 또는 24시간 단위로 url 주소가 변경되는 불편함이 있지만 돈을 내지 않는다는 장점이 있다!

---
#### 번외
 localtunnel은 더 자주 url이 변경되는 불편함이 있어, ngrok를 사용했다.

```bash
ngrok는 1개 서버만 접속 가능해서, localtunnel 사용
1. node.js 설치
2. npm install -g localtunnel

lt --port 8080 --subdomain backend
your url is: https://itchy-monkey-95.loca.lt

lt --port 8082 --subdomain webview
your url is: https://webview.loca.lt

ssh 인증서를 pc에 발급받고 이를 설정하는 방법도 있는데, 제일 복잡하고 코드에 내용을 추가하는 부분이 발생해서 포기했다.

그래서 추가 개발이 있을 때, 사이드 이펙트도 터지고 불필요한 검수도 하게 되고 여러모로 번거로움이 있어 프로젝트를 분리하게 되었다.

정말 간단한 어드민 페이지로, 프론트는 그대로 1개 백엔드는 서비스 단위로 2개로 분리했다. 어떻게?

1. 백엔드 분리

1. jwt 로 로그인 검증을 하는 프로젝트로 security에 대한 로직은 두개 프로젝트에 모두 존재하고, 대신 로그인에 관련된 컨트롤러는 기존 프로젝트에 두었다.
2. 그리고 충돌되지 않도록 새로운 미사용 포트를 잡아주면 끝!

2. 프론트 연결

프론트는 vuejs를 사용중이고, 기존에는 서버로 프록시하는 주소가 다 하나의 port로 요청되고, url 주소의 첫 경로가 /api로 시작되었기 때문에 1개의 프록시만 설정하면 되었는데 포트가 분리되면서 이에 대한 정보를 추가해야 한다.

//vite.config.ts
...
server: {
    proxy: {
    //1번 서비스
      "/api/admin/aaa": {
        target: 'http://localhost:8050', 
        changeOrigin: true,
        secure: false,
        // rewrite: (path) => path.replace(/^\/api/, '')
      },


      //2번 서비스
      "/api/admin/bbb": {
        target: 'http://localhost:8060',
        changeOrigin: true,
        secure: false,
        rewrite: (path) => path.replace(/^\/api\/admin\/bbb/, '/api/admin/bbb'),
      }
    }
  },
  ...

rewrite는 생략해도 되는 내용 생각보다 쉽당!

개발을 하다보면, 프로젝트에 대한 문서가 필요한 경우가 있다. 프론트, 앱 개발자와 소통하는 목적일 수도 있고, 어떤 API가 구현되있는지 확인하는 목적일 수도 있다.

Spring Boot에서 가장 흔하게 사용하는 DOCS는 Spring Docs와 Swagger가 있다. Spring Docs는 Controller Test를 만들어야 Docs가 생성되기 때문에 1석 2조로 활용할 수 있지만, 그만큼 개발 비용이 많이 든다. Swagger API 는 간단하게 만들 수 있지만, Controller 메소드 상단에 annotation으로 추가해서, 실제 코드의 가독성을 떨어트리는 단점이 있다.

만약, Controller에 작성하지 않고 간단하게 Swagger API를 사용할 수 있다면?!!

Swagger를 활용해서 example로 샘플 데이터를 보여주는 경우가 있는데 샘플 데이터가 너무 길어지면, swagger에 대한 설정만 10줄은 쉽게 넘기는 경우가 있었다. 이런 경우, example를 yml 또는 properties 파일로 분리하고 해당 내용을 호출해서 사용할 수 있을까?하고 확인해보았다.

1. example.yml 파일 생성 spring boot에서는 application.yml 파일 이외의 값은 import되지 않아서 swagger 내용에만 활용할 yml 파일을 만든다면, application.yml에 해당 파일을import한다는 설정이 필요하다.

   //application.yml
   

spring: config: import: classpath:docs/example.yml, classpath:docs/totalDashboard.yml //swagger에 example이 될만한 코드를 import

스웨거 설정(spring doc)

springdoc: swagger-ui: path: /api/promotion/swagger-ui defaultModelsExpandDepth: -1 # 모델(Schemas) 영역을 최소화 / -1은 아예 화면에서 사라짐, 0은 최소화

classpath까지는 src/resources의 경로고, 그 하위에 디렉토리 및 파일 위치를 명시하면 된다.만약 추가하는 파일이 2개 이상이라면, 콤마(,)로 이어서 작성하면 된다.

swagger api는 api영역과 schemas(dto)영역이 존재하는데
schemas는 결국 api 하위에 포함된 내용으로 해당 내용을 최소화하고 싶다면, 위와 같은 설정을 추가하면 된다.


2. example.yml 파일 

landingPageThemeByPromotionType: response: example: | { "statusCode": 200, "status": "정상", "data": [ { "idx": 8, "themeName": "캐릭터", "sampleImagePath": "S3 버킷 주소" }, ... ] }

S3 버킷 주소는 회사명이 담겨서 string 값으로 변경하고, 이런 식으로 값을 추가하면 된다.
| 하위의 내용은 알아서 줄바꿈이 yml 파일과 동일하게 적용되서, swagger api에서 보인다.

3. Controller 내 example에 추가 (실패한 방법)

@Value("${landingPageThemeByPromotionType.response.example}") private String themeResponseExample;

@Operation(summary = "프로모션 타입별 랜딩 페이지 테마 조회 API", description = "프로모션 등록 시, 업체에 해당하는 테마가 보이게 하는 조회 API")
@ApiResponses(value = {
        @ApiResponse(responseCode = "200",
            content = {@Content(schema = @Schema(implementation = ResponseThemeDto.class),
            mediaType = "application/json",
            examples = @ExampleObject(value = themeResponseExample))})
})

@Value 어노테이션은 Java 상수나 필드에서만 사용 가능해서, @ExampleObject의 value 속성에 직접 선언하는 방식은 지원하지 않는다. 
그래서 @Value로 선언하고, 이를 다시 호출하는 방식으로 사용해야 한다.

**그런데, Attribute value must be constant 라고 컴파일이 되지 않는다!!**
@Value는 어노테이션의 속성으로 사용할 수 없어서, 선언 후 호출하더라도 결국 에러가 발생하는 것이다.
이 문제를 해결하려면 미리 데이터를 읽어와서 주입한 후에 사용하는 방법을 사용해야 한다고 한다.

import org.springdoc.core.customizers.OpenApiCustomizer; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration;

@Configuration public class SwaggerConfig {

@Value("classpath:docs/example.yml")
private String themeResponseExample;

@Bean
public OpenApiCustomizer customizeOpenApi() {
    return openApi -> {
        openApi.getPaths().get("/theme").getGet().getResponses().get("200")
            .getContent().get("application/json").getExamples().put("example-1",
            new io.swagger.v3.oas.models.examples.Example().value(themeResponseExample));
    };
}

}

이런 식으로 SwaggerConfig 클래스에 동적으로 데이터를 주입하는 방법을 사용해야 한다고 한다.
> Swagger API를 Controller와 SwaggerConfig 2개 클래스에서 관리한다면, 유지보수의 번거로움도 있고 가독성이 역시 좋지 않다고 생각이 들었다.
**그러면 SwaggerConfig에 합쳐서 작성하는 방법은 없을까?**

4. SwaggerConfig 클래스에 api 명세에 대한 모든 내용을 추가하자!

import com.fasterxml.jackson.databind.ObjectMapper; import io.swagger.v3.oas.models.Components; import io.swagger.v3.oas.models.OpenAPI; import io.swagger.v3.oas.models.info.Info; import io.swagger.v3.oas.models.responses.ApiResponse; import io.swagger.v3.oas.models.media.Content; import io.swagger.v3.oas.models.media.MediaType; import io.swagger.v3.oas.models.examples.Example; import io.swagger.v3.oas.models.media.Schema; import io.swagger.v3.oas.models.responses.ApiResponses; import io.swagger.v3.oas.models.Operation; import io.swagger.v3.oas.models.parameters.Parameter; import io.swagger.v3.oas.models.PathItem; import io.swagger.v3.oas.models.security.SecurityRequirement; import io.swagger.v3.oas.models.security.SecurityScheme; import org.springdoc.core.customizers.OpenApiCustomizer; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.PropertySource;

import java.io.IOException; import java.util.Arrays; import java.util.List;

@Configuration @PropertySource(value = "classpath:docs/example.yml", encoding = "UTF-8") // UTF-8로 인코딩 설정 public class SwaggerConfig { @Value("${server.name}") private String serverName;

@Value("${landingPageThemeByPromotionType.response.example}")
private String themeResponseExample;

@Bean
public OpenAPI customOpenAPI() {
    return new OpenAPI()
            .info(new Info()
                    .title("promotion API document - " + serverName)
                    .description("[" + serverName + "] 프로모션 백엔드 api 문서 - ")
                    .version("1.0.0"))
            .components(new Components()
                    .addSecuritySchemes("bearerAuth",
                            new SecurityScheme()
                                    .type(SecurityScheme.Type.HTTP)
                                    .scheme("bearer")
                                    .bearerFormat("JWT")))
            .addSecurityItem(new SecurityRequirement().addList("bearerAuth"));
}


@Bean
public OpenApiCustomizer customizeLandingPageThemeApi() throws IOException {
    // JSON 문자열을 객체로 변환
    ObjectMapper objectMapper = new ObjectMapper();
    Object themeResponseExampleObject = objectMapper.readValue(themeResponseExample, Object.class);

    return openApi -> {
        openApi.path("/api/promotion/landingPage/theme", new PathItem()
                .get(new Operation()
                        .summary("프로모션 타입별 랜딩 페이지 테마 조회 API")
                        .description("프로모션 등록 시, 업체에 해당하는 테마가 보이게 하는 조회 API")
                        .addTagsItem("LandingImageController") // Tag 추가
                        .responses(new ApiResponses()
                                .addApiResponse("200", new ApiResponse()
                                        .description("정상 응답")
                                        .content(new Content()
                                                .addMediaType("application/json", new MediaType()
                                                        .schema(new Schema().$ref("#/components/schemas/ResponseThemeDto"))
                                                        .example(new Example().value(themeResponseExampleObject)))))
                        )
                        .addParametersItem(new Parameter()
                                .name("customerCd")
                                .in("query") //파라미터가 어디에 포함되는지 나타냄
                                .required(true)
                                .schema(new Schema<Integer>().type("integer"))
                                .description("고객 코드")
                                .example(121438))
                        .addParametersItem(new Parameter()
                                .name("promotionType")
                                .in("query")
                                .required(true)
                                .schema(new Schema<Integer>().type("integer"))
                                .description("프로모션 타입")
                                .example(1))
                ));
    };
}

}

```

이렇게 하면, swagger 코드가 길어지면서 controller의 가독성을 해치는 문제도 해결되고 모든 api의 내용을 한 파일에서 관리할 수 있게 된다.

메소드 내부 내용

1. .in .는 OpenAPI 명세에서 파라미터가 어디 위치하는지 나타내는 속성이다.
   1. query: URL의 쿼리 문자열에 파라미터가 포함됩니다. 예: /api/users?id=123 path: URL 경로의 일부로 파라미터가 포함됩니다. 예: /api/users/{id} header: HTTP 헤더에 파라미터가 포함됩니다. cookie: 쿠키에 파라미터가 포함됩니다. body: HTTP 요청 본문에 파라미터가 포함됩니다 (주로 POST, PUT 요청에서 사용).

만약 컨트롤러가 있지만, 당장 사용하고 있지 않는 내용이라면? @Hidden을 Controller layer에 붙이면, 해당 컨트롤러에 대한 api는 swagger에 포함되지 않는다. method layer에도 물론 추가할 수 있는 어노테이션이다.

오히려 너무 많은 메소드가 담기면, 가독성이 더 떨어지려나?

1. WebMvcConfigurer를 implements한 config 클래스를 만들고, 내부에 messageSource 빈 등록을 해야함

2. resource 내에 properties를 국가별로 별도로 생성한다.

//3. jsp파일에서 태그로 값을 읽는다.
<spring:message code="sample.hello">

properties 개행

properties 파일 내에 텍스트가 jsp 내에서 읽는데, 개행이 필요한 경우 \n이 아닌, < br/> 태그를 사용하면 된다.

vue.js에서 다국어 버전 적용

jsp와 유사하지만, 프로퍼티 파일이 아닌 제이슨으로 설정해서 더 간단한 것 같다.

1. src 하위에 locale 폴더 생성 후, 하위에 언어별 폴더와 폴더명과 동일한 이름의 json 파일 생성 폴더명은 무관하지만, 해당 언어를 인지하기 좋게 작성하는 것이 좋음 언어별 같은 키값에 번역 내용을 value로 설정한 json 파일 저장.

2. src 하위에 i18n.js, main.js 생성 i18n.js

   import Vue from 'vue'
   import VueI18n from 'vue-i18n'
   

// json 파일을 읽어들이기 위한 function const requireLang = require.context( '@/locales', // 폴더명 입니다. true, /.json$/ // 폴더 아래 json 찾기용 )

const messages = {}

// json file read for (const file of requireLang.keys()) { const path = file.replace(/(./|.json$)/g, '').split('/') // 폴더 패스

path.reduce((o, s, i) => { if (o[s]) return o[s]

o[s] = i + 1 === path.length
  ? requireLang(file)
  : {}

return o[s]

}, messages)

}

Vue.use(VueI18n);

const i18n = new VueI18n({ locale: 'ko', // 기본 locale fallbackLocale: 'ko', // locale 설정 실패시 사용할 locale messages, // 다국어 메시지 silentTranslationWarn: true // 메시지 코드가 없을때 나오는 console 경고 off })

export default i18n

main.js

import Vue from 'vue' import App from './App.vue' import i18n from './i18n'

Vue.config.productionTip = false

new Vue({ i18n, render: h => h(App), data: { foo:"test" } }).$mount('#app')

3. {{ $t('  json파일명.변수명 ') }}으로 태그 내부에 작성 <>요기에<>


---
---
# Vue.js / typescript
vue.js 환경에서 다국어 작업 (typescript)
vue도 typescript도 써본 적이 없어(사실 프론트 자체를 거의 안해본,,,) chatGPT의 도움을 많이 받아서 다국어 작업을 진행했다.

다국어 작업으로 화면에서 처리가 추가적으로 필요하지만
세팅하고 어떻게 하면 다국어가 적용된 값을 불러올 수 있는지 정리해본다.

1. main.ts
//spring boot에서는 gradle 격인 느낌이다.

//main.ts import { createApp } from 'vue'; import { createI18n } from 'vue-i18n';

import en from '@/utils/locales/en.json'; import ko from '@/utils/locales/ko.json'; import vi from '@/utils/locales/vi.json'; import jp from '@/utils/locales/jp.json'; import cn from '@/utils/locales/cn.json';

type MessageSchema = typeof en; const i18n = createI18n<[MessageSchema], 'ko' | 'en' | 'vi' | 'jp' | 'cn'>({ // options locale: 'ko', fallbackLocale: 'en', legacy: false, messages: { en: en, ko: ko, vi: vi, jp: jp, cn: cn } // , // silentTranslationWarn: true, // silentFallbackWarn: true });

const app = createApp(App); app.use(i18n); app.use(vuetify).mount('#app'); // vuetify는 생략 가능하다.

> main.ts 에서 vue-i18n을  import해주고, 각 언어별 json 파일을 import해준다.
> MessageSchema는 한 개의 json 파일을 type으로 지정해주는 것 같다.
> 그래서 type 지정된 json 내부에 있는 단어가 다른 json 파일에는 없다면 에러가 발생한다.
>
> legacy는 false로 해두어야 Composition API에서 사용 가능하다고 한다.
> 내가 사용하려는 언어별 파일을 messages에 추가한다.(import되있어야 함)


2. vite.config.ts

//vite.config.ts ... import path from 'node:path'; // import vueI18n from '@intlify/vite-plugin-vue-i18n' // 설치 import VueI18nPlugin from '@intlify/unplugin-vue-i18n/vite'; // vite ver4 이상

// https://vitejs.dev/config/ export default defineConfig({ plugins: [

//plugins에 추가 VueI18nPlugin({ include: [path.resolve(__dirname, './src/utils/locales/**')], }) ], resolve: { alias: { ... 'vue-i18n': 'vue-i18n/dist/vue-i18n.esm-bundler.js' } }, ... });

3. LanguageSelector.vue

// /src/components/LanguageSelector.vue

4. useLanguageSelector.ts

// /src/composables/useLanguageSelector.ts // LanguageSelectorScript.ts import { ref, onMounted, onBeforeUnmount } from 'vue'; import { useI18n } from 'vue-i18n';

export function useLanguageSelector() { const showDropdown = ref(false); const currentLang = ref('ko'); // default language const languages = [ { id: 'en', src: '/src/assets/images/lang/en.png' }, { id: 'cn', src: '/src/assets/images/lang/cn.png' }, { id: 'jp', src: '/src/assets/images/lang/jp.png' }, { id: 'vi', src: '/src/assets/images/lang/vi.png' }, { id: 'ko', src: '/src/assets/images/lang/ko.png' } ];

const currentFlag = ref(/src/assets/images/lang/${currentLang.value}.png); const { locale } = useI18n();

const toggleDropdown = () => { showDropdown.value = !showDropdown.value; };

const selectLang = (lang: string) => { currentLang.value = lang; currentFlag.value = /src/assets/images/lang/${lang}.png; showDropdown.value = false; // Save selected language in localStorage or make API call to update language preference localStorage.setItem('lang', lang); locale.value = lang; };

const handleClickOutside = (event: MouseEvent) => { const target = event.target as HTMLElement; if (!target.closest('.lang-selector')) { showDropdown.value = false; } };

onMounted(() => { document.addEventListener('click', handleClickOutside); });

onBeforeUnmount(() => { document.removeEventListener('click', handleClickOutside); });

return { showDropdown, languages, currentFlag, toggleDropdown, selectLang }; }

처음에는 vue 파일 내부에 script 코드도 포함해서 만들었지만, 그러면 다국어가 반영되어야 하는 코드(script만 필요한 코드) 내부에도 국기를 선택하는 화면이 추가되기 때문에 script와 화면을 구성하는 vue로 나눴다. (vue 파일에 들어간 script 코드는 국기를 선택하면 되어야 하는 동작이 들어가있다.)

locale 디렉토리 내부에 각 국가별 json 파일을 추가하고, images에도 국기 모양을 선택하고(국기 모양으로 헤더에 보여지기 위함)한다.

5. header.vue

//header.vue

헤더에서는 국기를 선택하는 화면과 선택 후 헤더에 포함된 글자도 다국어 처리되어야 하기 때문에 두가지 모두 import한다.

6. xxxx.vue

vue에서 watchEffect, computed 를 import한다.
watchEffect는 콜백 함수 안에 반응성 데이터 변화가 감지되면 자동으로 실행
script의 변수 내부에서는 computed 함수 호출하고, t('startDt')로 사용 가능
template 내부에서는 <> 안에 있는 attribute라면, :label="$t('overall')" 으로 사용 가능(:으로 무조건 시작해야함), <><>사이에 있는 값이라면 {{ $t('search') }} 이런 식으로 사용 가능

## json 개행
properties 파일은 <br.> 태그로 개행을 해야하지만(태그 보이기 위해 점찍음), 
json의 경우 \n으로 개행이 읽힌다. 오히려 br 태그를 붙이는 경우 프론트 페이지 에러가 난다.

• 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.
• 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.
• 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다.
• 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다.

형식을 맞추는 목적

• 코드 형식은 의사소통의 일환이다. 돌아가는 코드가 전문 개발자의 일차적인 의무라고 생각할 수 있지만, 코드 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.

1. 적절한 행 길이를 유자하라

신문 기사처럼 작성하라

• 이름은 간단하면서 설명이 가능하게 짓고, 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지 판단할 정도로 신경 써서 짓는다.
• 첫 부분은 고차원 개념과 알고리즘을 설명하고, 아래로 내려올수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다.

  개념은 빈 행으로 분리하라

• 거의 모든 코드는 왼쪽에서 오른쪽, 위에서 아래로 읽힌다.
• 각 행은 수식이나 절을 나타내고, 일련의 행 묶음은 완결된 생각 하나를 표현한다. 생각 사이에는 빈 행을 넣어 분리해야 마땅하다.

package fitnesse.wikitext.widgets;

import java.uitl.regex.*;

public class BoldWidget extends ParentWidget {
    public static final String REGXP = "'''.+?'''";
    private static final Patten patten = Patten.compile("'''(.+?)'''",
        Patten.MULTILINE + Patten.DOTALL
    );

    public BoldWidget(ParentWidget parent, String text) throws Exception {
        super(parent);
        Matcher match = patten.matcher(text);
        match.find();
        addChildWidgets(match.group(1));
    }

    public String render() throws Exception {
        StringBuffer html = new StringBuffer("<b>");
        html.append(childHtml().append("<b>");
        return html.toString();
    }
}

package fitnesse.wikitext.widgets;
import java.uitl.regex.*;
public class BoldWidget extends ParentWidget {
    public static final String REGXP = "'''.+?'''";
    private static final Patten patten = Patten.compile("'''(.+?)'''",
        Patten.MULTILINE + Patten.DOTALL
    );
    public BoldWidget(ParentWidget parent, String text) throws Exception {
        super(parent);
        Matcher match = patten.matcher(text);
        match.find();
        addChildWidgets(match.group(1));
    }
    public String render() throws Exception {
        StringBuffer html = new StringBuffer("<b>");
        html.append(childHtml().append("<b>");
        return html.toString();
    }
}

위와 아래는 동일한 코드인데, 빈 행 유무의 차이만 있다. 빈 행이 없어지면, 코드 가독성이 현저하게 떨어져 암호처럼 보인다.

세로 밀집도

• 줄바꿈이 개념을 분리한다면, 세로 밀집도는 연관성을 의미한다.

  public class ReporterConfig {
    /**
    * 리포터 리스너의 클래스 이름
    */
    private String m_className;
  
    /**
    * 리포터 리스너의 속성
    */
    private List<Property> m_properties = new ArrayList<Property>();
    public void addProperty(Property property) {
        m_properties.add(property);
    }
  }

  public class ReporterConfig 
    private String m_className;
    private List<Property> m_properties = new ArrayList<Property>();
  
    public void addProperty(Property property) {
        m_properties.add(property);
    }
  }

  위에 주석이 있는 코드보다, 아래 코드가 '한 눈'에 들어온다.

수직 거리

• 서로 밀접한 개념은 세로로 가까이 둬야 한다. 물론 두 개념이 서로 다른 파일에 속한다면 규칙이 통하지 않지만, 타당한 근거가 없다면 서로 밀접한 개념은 한 파일에 속해야 마땅하다. 이 것이 바로 protected 변수를 피해야 하는 이유 중 하나다.
• 밀접한 두 개념은 세로 거리로 연관성을 표현한다.
• 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도로, 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다.

  변수 선언

  변수는 사용하는 위치에 최대한 가까이 선언한다. 루프를 제어하는 변수는 흔히 루프 문 내부에 선언한다.

인스턴스 변수

인스턴스 변수는 클래스 맨 처음에 선언한다. 또한, 변수 간에 세로로 거리를 두지 않는다.

종속 함수

한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 그러면 프로그램이 자연스럽게 읽힌다.

개념적 유사성

친화도가 높을수록 코드를 가까이 배치한다. 친화도가 높은 요인은 여러 가지다. 한 함수가 다른 함수를 호출해 생기는 직접적인 종속성이 한 예이고, 변수와 그 변수를 사용하는 함수도 한 예이다. 아래 예시는 명명법이 같고 기본 기능이 유사하고 간단하다. 종속적인 관계가 없더라도 가까이 배치해야할 함수들이다.

public class Assert {
    static public void assertTrue(String message, boolean condition) {
        if(!condition) 
            fail(message);
    }

    static public void assertTrue(boolean condition) {
        assertTrue(null, condition);
    }

    static public void assertFalse(String message, boolean condition) {
        assertTrue(message, !condition);
    }

    static public void assertFalse(boolean condition) {
        assertFalse(null, condition);
    }
}

세로 순서

• 일반적으로 함수 호출 종속성은 아래 방향으로 유지한다.
• 호출되는 함수를 호출하는 함수보다 나중에 배치하면, 소스 코드 모듈이 고차우너에서 저차원으로 자연스럽게 내려간다.

가로 형식 맞추기

• 가급적 120자 이상을 넘지 않는 것이 좋다.

가로 공백과 밀집도

private void measureLine(String line) {
    lineCount++;
    int lineSize = line.length();
    totalChars += lineSize;
    lineWithHistogram.addLine(lineSize, lineCount);
    recordWidgetLine(lineSize);
}

• 할당 연산자를 강조하려고 앞뒤에 공백을 줬다. 할당문은 왼쪽 요소와 오른쪽 요소가 분명히 나뉜다. 공백을 넣으면 두 가지 주요 요소가 확실히 나뉜다는 사실이 더욱 분명해진다.

• 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않았다. 함수와 인수는 서로 밀접하기 때문이다. 공백을 넣으면 한 개념이 아닌 별개로 보인다.

• 함수를 호출하는 인수는 쉼표를 강조해 인수가 별개라는 사실을 보여주기 위해 가로 공백을 준다.

• 연산자 우선 순위를 강조하기 위해서도 공백을 사용한다.

public class Quadratic {
    public static double root1(double a, double b, double c) {
        double determinant = determinant(a, b, c);
        return (-b + Math.sqrt(determinant)) / (2*a);
    }

    public static double root2(int a, int b, int c) {
        double determinant = determinant(a, b, c);
        return (-b - Math.sqrt(determinant)) / (2*a);
    }
    private static double determinant(double a, double b, double c) {
        return b*b - 4*a*c;
    }
}

• 곱셈은 우선 순위가 가장 높아서, 승수 사이에는 공백이 없다. ex)2a, 4a*c
• 덧셈과 뺄셈은 곱셈보다 우선 순위가 낮기 때문에, 항 사이에는 공백이 들어간다.

가로 정렬

• 이전에는 변수를 선언할 때, 가로 공백을 맞춰서 나란히 정렬했으나, 이제는 선언문과 할당문을 별도로 정렬하지 않는다. 정렬하지 않으면 오히려 중대한 결함을 찾기가 쉽다.

들여쓰기

• 코드는 윤곽도(outline) 계층과 비슷하며, 이러한 범위로 이루어진 계층을 표현하기 위해 우리는 코드를 들여쓴다.
• 들여쓰는 정도는 계층에서 코드가 자리잡은 수준에 비례한다.
• 클래스 정의처럼 파일 수준의 문장은 들여쓰지 않고, 클래스 내 메서드는 클래스보다 한 수준 들여쓴다.
• 메소드 코드 내부는 메소드 선언보다 한 수준 들여쓰고, 블로코드는 블록을 포함하는 코드보다 한 수준 들여쓴다.

들여쓰기 무시하기

public class CommentWidget extends TextWidget 
{
    public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r?";

    public CommentWidget(ParentWidget parent, String text) {super(parent, text);}
    public String render() throws Exception{ return "";}
}

public class CommentWidget extends TextWidget {
    public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r?";

    public CommentWidget(ParentWidget parent, String text) {
    super(parent, text);
    }
    public String render() throws Exception{ 
        return "";
    }
}

가짜 범위

• 비어있는 while문이나 for문을 사용하지 않는 것이 좋지만, 만약 사용하게 되는 경우 새 행에 세미콜론을 들여써서 넣어준다.

팀 규칙

• 프로그래머는 각자 선호하는 규칙이 있지만, 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.
• 팀은 한 가지 규칙에 합의해야 하고, 모든 팀원은 그 규칙을 따라야 한다.
• 좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억해야 한다.
• 스타일은 일관적이고 매끄러워야 하며, 한 형식이 다른 소스 파일에도 쓰이라는 신뢰가 필요하다.

public class CodeAnalyzer implements JavaFileAnalysis { 
    private int lineCount;
    private int maxLineWidth;
    private int widestLineNumber;
    private LineWidthHistogram lineWidthHistogram; 
    private int totalChars;

    public CodeAnalyzer() {
        lineWidthHistogram = new LineWidthHistogram();
    }

    public static List<File> findJavaFiles(File parentDirectory) { 
        List<File> files = new ArrayList<File>(); 
        findJavaFiles(parentDirectory, files);
        return files;
    }

    private static void findJavaFiles(File parentDirectory, List<File> files) {
        for (File file : parentDirectory.listFiles()) {
            if (file.getName().endsWith(".java")) 
                files.add(file);
            else if (file.isDirectory()) 
                findJavaFiles(file, files);
        } 
    }

    public void analyzeFile(File javaFile) throws Exception { 
        BufferedReader br = new BufferedReader(new FileReader(javaFile)); 
        String line;
        while ((line = br.readLine()) != null)
            measureLine(line); 
    }

    private void measureLine(String line) { 
        lineCount++;
        int lineSize = line.length();
        totalChars += lineSize; 
        lineWidthHistogram.addLine(lineSize, lineCount);
        recordWidestLine(lineSize);
    }

    private void recordWidestLine(int lineSize) { 
        if (lineSize > maxLineWidth) {
            maxLineWidth = lineSize;
            widestLineNumber = lineCount; 
        }
    }

    public int getLineCount() { 
        return lineCount;
    }

    public int getMaxLineWidth() { 
        return maxLineWidth;
    }

    public int getWidestLineNumber() { 
        return widestLineNumber;
    }

    public LineWidthHistogram getLineWidthHistogram() {
        return lineWidthHistogram;
    }

    public double getMeanLineWidth() { 
        return (double)totalChars/lineCount;
    }

    public int getMedianLineWidth() {
        Integer[] sortedWidths = getSortedWidths(); 
        int cumulativeLineCount = 0;
        for (int width : sortedWidths) {
            cumulativeLineCount += lineCountForWidth(width); 
            if (cumulativeLineCount > lineCount/2)
                return width;
        }
        throw new Error("Cannot get here"); 
    }

    private int lineCountForWidth(int width) {
        return lineWidthHistogram.getLinesforWidth(width).size();
    }

    private Integer[] getSortedWidths() {
        Set<Integer> widths = lineWidthHistogram.getWidths(); 
        Integer[] sortedWidths = (widths.toArray(new Integer[0])); 
        Arrays.sort(sortedWidths);
        return sortedWidths;
    } 
}

6. 객체와 자료 구조

변수를 비공개로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 하지만 수많은 프로그래머가 조회함수와 설정함수(getter, setter)를 당연하게 공개해 비공개 변수를 외부에 노출할까?

자료 추상화

public class Point {
    public double x;
    public double y;
}

public interface Point {
    double getX();
    double getY();
    void setCartesian(double x, double y);
    double getR();
    double getTheta();
    void setPolar(double r, double theta);
}

• 두 클래스 모두 2차원 점을 표현하지만, 위에 클래스는 구현을 외부로 노출하고 밑에 클래스는 구현을 완전히 숨긴다.
• 변수를 private으로 설정하더라도, getter/setter를 제공한다면 구현을 외부로 노출하는 셈이다. 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지 않는다.
• 구현을 감추려면 추상화가 필요하다. > 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.

public interface Vehicle {
    double getFuelTankCapacityInGallons();
    double getGallonsOfGasoline();
}    

public interface Vehicle {
    double getPercentFuelRemaining();
}

상위 인터페이스는 자동차 연료 상태를 구체적인 숫자로 알려주지만, 하위 인터페이스는 자동차 연료 상태를 백분율이라는 추상적인 개념으로 알려준다. 상위 인터페이스는 변수값을 읽어 반환할 뿐이라는 사실이 거의 확실하지만, 하위 인터페이스는 정보가 어디서 오는지 전혀 드러나지 않는다.

자료/객체 비대칭

• 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
• 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.
• 객체와 자료구조의 정의는 본질적으로 상반된다.

절차적인 도형
public class Square {
    public Point topLeft;
    public double side;
}

public class Rectangle {
    public Point topLeft;
    public double height;
    public double width;
}

public class Circle {
    public Point center;
    public double radius;
    public double width;
}

public class Geometry {
    public final double PI = 3.141592653585793;

    public double area(Object shape) throws NoSuchShapeException {
        if(shape instanceOf Square) {
            Square s = (Square)shape;
            return s.side * s.side;
        }
    else if(shape instanceOf Rectangle) {
            Rectangle r = (Rectangle)shape;
            return r.height * r.width;
        }
    else if(shape instanceOf Circle) {
            Circle c = (Circle)shape;
            return PI * c.radius * c.radius
        }
    }
    throw new NoSuchShapeException();
}

Geometry 클래스는 세 가지 도형 클래스를 다루고, 각 도형 클래스는 간단한 자료 구조이다. 즉, 자료구조인 각 도형 클래스에서는 아무 메소드를 제공하지 않고, 도형이 동작하는 방식은 Geometry라는 객체에서 구현한다.

• 클래스가 절차적이지만, 만약 둘레 길이를 구하는 함수를 추가하고 싶다면, 각 도형 클래스에는 아무런 영향을 미치지 않는다.
• 반대로 새 도형을 추가하고 싶다면, Geometry 클래스에 속한 함수를 모두 고쳐야 한다.

다형적인 도형(객체지향적 도형)
public class Square implements Shape {
    public Point topLeft;
    public double side;

    public double area() {
        return side*side;
    }
}

public class Rectangle implements Shape {
    public Point topLeft;
    public double height;
    public double width;

    public double area() {
        return height*width;
    }
}

public class Circle implements Shape {
    public Point center;
    public double radius;
    public double width;

    public double area() {
        return PI*radius*radius;
    }
}

area 메소드는 다형 메소드로, Geometry 클래스는 필요하지 않다. 새 도형을 추가하고 싶더라도 기존 함수에 아무런 영향을 주지 않지만, 새 함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야 한다.

• 절차 지향과 객체 지향은 상호 보완적인 특질이 있어, 객체와 자료구조는 근본적으로 양분된다.

(자료 구조를 사용하는)절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

절차적인 코든느 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체 지향 코든느 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.

객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉽고, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다.

디미터 법칙

• 디미터 법칙은 잘 알려진 휴리스틱(발견법)으로 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 객체는 자료를 숨기고 함수를 공개한다.
• 즉, 객체는 getter로 내부 구조를 공개하면 안된다는 의미다.

  클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다.
  

클래스 C f가 생성한 객체 f 인수로 넘어온 객체 C 인스턴스 변수에 저장된 객체

쉽게 말해, 낯선 사람은 경계하고 친구랑만 놀라는 의미다.

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

#### 기차 충돌
- 여러 객차가 한 줄로 이어진 기차처럼 보여서, 위와 같은 코드를 기차 충돌이라고 부른다.
- 일반적으로 조잡하다고 여겨지는 방식으로 피하는 것이 좋다.

Options opts = ctxt.getOption(); File scratchDir = opts.getScratchDir(); final String outputDir = scratchDir.getAbsolutePath();

기차 충돌 코드는 이처럼 수정하는 것이 좋지만, getter를 사용하는 바람에 디미터 법칙을 위반한 것인지 혼란을 일으킨다.

final String outputDir = ctxt.options.scratchDir.absolutPath;

위 코드처럼 구현한다면, 디미터 법칙을 거론할 필요가 없어진다.

#### 잡종 구조
- 이런 혼란으로 절반은 객체, 절반은 자료 구조인 잡종 구조가 나온다. 
- 잡종 구조는 중요한 기능을 수행하는 함수도 있고, 공개 변수나 공개 getter/setter도 있으며, getter/setter는 비공개 변수를 그대로 노출한다.
- 이 때문에 다른 함수가 절차적인 프로그래밍의 자료 구조 접근 방식처럼 비공개 변수를 사용하고픈 유혹에 빠지기 쉽다.
- 잡종 구조는 객체, 자료 구조의 단점만 모아놓는 구조로, 되도록 잡종 구조는 피하는 것이 좋다.

#### 구조체 감추기
만약 ctxt, options, scratchDir이 진짜 객체라면, 기차 충돌 코드를 사용하면 안된다. 

// 1번 ctxt.getAbsolutePathOfScratchDirectoryOption();

// 2번 ctxt.getScratchDirectoryOption().getAbsolutePath()

// 3번 BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

첫 번째 방법은 ctxt 객체에 공개해야 하는 메서드가 너무 많아지고,
두 번째 방법은 getScratchDirectoryOption()이 객체가 아닌 자료 구조를 반환한다고 가정한다.
세 번째 방법은 ctxt 객체에 임시 파일을 생성하도록 하는 것으로, 객체에서 맡기기 적당한 임무로 보인다.
또한, ctxt 내부 구조를 드러내지 않으며, 모듈에서 자신이 몰라야 하는 여러 객체를 탐색할 필요가 없기에 디미터 법칙을 위반하지 않는다.

#### 자료 전달 객체
- 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스로, 이런 자료 구조체를 자료 전달 객체(Data Transfer Object, DTO)라고 한다.
- DTO는 데이터베이스와 통신하거나 소켓에서 받은 메세지의 구문을 분석할 때 유용하다.
- DTO는 데이터베이스에 저장된 가공되지 않은 정보를 애플리케이션 코드에서 사용할 객체로 변환하는 일련의 단계에서 가장 처음으로 사용하는 구조체다.
- 좀 더 일반적인 형태는 빈(bean) 구조다. 빈은 비공개 변수를 getter/setter로 조작한다. 일종의 사이비 캡슐화로 별다른 이익을 제공하진 않는다.

class Address {

private final String postalCode;

private final String city;

private final String street;

private final String streetNumber;

private final String apartmentNumber;

public Address(String postalCode, String city, String street, String streetNumber, String apartmentNumber) {
    this.postalCode = postalCode;
    this.city = city;
    this.street = street;
    this.streetNumber = streetNumber;
    this.apartmentNumber = apartmentNumber;
}

public String getPostalCode() {
    return postalCode;
}

public String getCity() {
    return city;
}

public String street() {
    return street;
}

public String streetNumber() {
    return streetNumber;
}

public String apartmentNumber() {
    return apartmentNumber;
}

}

#### 활성 레코드(active record)
- 활성 레코드는 DTO의 특수한 형태이다. 공개 변수가 있거나 비공개 변수에 getter/setter 함수가 있는 자료 구조지만, 여기에 save, find와 같은 탐색 함수도 제공한다.
- 활성 레코드는 테이터 베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과다.
- 활성 레코드에 비지니스 규칙 메소드를 추가해 이런 자료 구조를 객체로 취급하는 개발자가 흔하지만, 이는 자료 구조도 객체도 아닌 잡종 구조가 나오기 때문에 바람직하지 않다.
- 활성 레코드는 자료 구조로 취급하고, 비지니스 규칙을 담으면서 내부 자료를 숨기는 객체는 따로 생성한다.

---
### 결론
- 객체는 동작을 공개하고 자료를 숨긴다. 그래서 동작을 변경하지 않으면서 새 객체 타입을 추가하기 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다.
- 자료구조는 별다른 동작없이 자료를 노출한다. 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.
- 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하다면, 객체가 적합하다.
- 새로운 동작을 추가하는 유연성이 필요하면, 자료 구조와 절차적인 코드가 적합하다.

우선 하루 매출 검색을 구현하는데, 내가 사용한 코드의 경우 dateRange 타입으로 attribute를 받아서 처리하는 방식이고 이를 응용해서 사용하려면 하루 날짜를 검색함에도 시작날짜와 끝날짜가 필요했다. 시작 날짜와 끝 날짜를 같은 날로 지정하고 검색하면 당연히 되겠거니 하고 구현을 하니, input으로 받은 date는 시작 날짜에만 value를 전달하고 끝 날짜는 값이 전달되지 않았다. hidden으로 시작 value를 옮겨주는 작업도 해봤지만, 되지 않았다. jquery와 태그 내부에서 모두 시도했지만, 빈값으로 받아짐ㅠㅠ 신기하게도 검색은 되는데!ㅋㅋㅋㅋㅋㅋㅋ url상 param이 비어있는 상황이었다.

안되는데 작동은 하는 상황인데, 이대로 계속하다가는 나중에 막 꼬일 것 같아서 다른 date range picker를 찾아봤다. https://preview.keenthemes.com/metronic/demo2/crud/forms/widgets/bootstrap-daterangepicker.html# 여기는 bootstrap daterangepicker라고 하는데, html과 javascript 코드만 복붙해서 만든 샘플 페이지에서는 아이콘이나 클릭했을 때 달력이 보이지 않았다. css 링크나 javascript를 사용할 코드의 링크를 안써준 문제 아이콘을 받을 수 있는 css 링크를 붙여주고 나니, 아이콘은 보이지만 정렬이나 디자인은 빠져있었다.

개발자 페이지에서 css 파일을 그대로 긁어와서 붙여주니, 모달을 제외한 기능은 들어왔는데 파일이 8만줄이 넘었곸ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 나는 모달을 사용하려고 하고 있기 때문에 또 확인을 해봐야 한다...

조그만 팝업의 이름이 모달인 것도 오늘 처음 알았닿ㅎㅎㅎㅎㅎ 야매로 프론트를 보면서 모달로 붙여주는 작업을 시도해야한다. 생각보다 시간이 오래 걸리겠는걸,,,,?ㅎㅎㅎㅎㅎㅎㅎ

와 하루종일 걸려서 너무 뿌듯해서 영상까지 업로드!ㅋㅋㅋㅋㅋㅋㅋㅋ 날짜나 월별 검색은 input으로 바로 받아서 가능한데, 기간별은 어떻게 해야하나 구글링하던 중에 date range picker라는 오픈소스를 찾았다!!! 설명은 frontbackend라는 페이지에서 볼 수 있다.

해당 페이지를 보면서 차근차근 따라해봤는데 gradle에 추가해주면서,버전때문에도 애먹고 빌드가 안되서도 애먹었다ㅠㅠ

//for date range picker
    implementation group: 'org.webjars', name: 'jquery', version: '3.0.0'
    implementation group: 'org.webjars', name: 'bootstrap', version: '4.0.0-2'
    implementation 'org.webjars:popper.js:1.12.9-1'
    implementation 'org.webjars:webjars-locator:0.45'
    implementation 'org.webjars:font-awesome:5.11.2'

총 다섯개의 디펜던시를 추가해줬는데, bootstrap이 5버전 이하라면 jquery를 추가해줘야 한다고 한다. 빌드를 한 열번 하면서 정상적으로 불러와질 때까지 해봤다.

그리고, controller와 index페이지를 똑같이 생성해서 실행해봤는데, 달력 모양이 나오지 않았다🙄 깃허브에 들어가서 css, js 파일을 복붙해주니 샘플 페이지는 정상적으로 작동되었다.

내가 사용하는 페이지에 적용하기 위해서 검색에 해당하는 div태그를 전체적으로 옮겨주고 script 부분과 css를 옮겨줬는데, 또 달력모양이 안나온다! 파일이 이제 다 static 내부에 있는데, 뭐가 문제인지 한참을 삽질하다가 경로 문제인 것을 확인했다. 나는 templates에 하위 디렉토리를 두고서 작업중인데, 그러면 static에 접근하기 위해 한 번 더 상위로 (../)나갔어야 했다! 너무 당연한 소리지만 css를 지이이이이잉이인짜 오랜만에 봐서 아예 생각도 못하던 부분이다.

이제 검색 껍데기는 보이는데, 날짜를 선택하고 검색할 때 검색 결과가 보일 수 있도록 변경해야 한다. 미리 만들어둔 period에 해당하는 메소드와 연결을 해야하는데, 나는 LocalDate를 사용했고, 오픈 소스에서는 Date를 사용한다.

public LocalDate convertFromDateToLocalDate(Date date) {
        return date.toInstant()
                .atZone(ZoneId.systemDefault())
                .toLocalDate();
}

Date를 LocalDate로 타입 변환을 할 수 있도록 메소드를 만들어주고, 기간별 매출조회에 해당하는 메소드와 연결해줬다. 그랬더니 계속 아래와 같은 오류가 발생했다.... Failed to convert from type [java.lang.String] to type [@org.springframework.format.annotation.DateTimeFormat java.util.Date] 에러 코드를 보면, 날짜가 DD/MM/YYYY 형식으로 보이는데 내가 Format으로 맞춰준 날짜의 형식은 모두 YYYY-MM-DD 타입이다. 보이는 모든 부분은 수정했는데도 문제가 안나와서 command + shift + F로 (dd/mm/yyyy)를 검색했다ㅋㅋㅋㅋㅋ 그랬더니 script부분에서 picker.startDate.format 내부가 DD/MM/YYYY로 적혀있었다. startDate, endDate 부분을 모두 수정하고 나니 정상적으로 검색된다!!

    var $dateRange = $('#dateRange');

    $dateRange.daterangepicker();
    $dateRange.on('apply.daterangepicker', function (ev, picker) {
        $('input[name="dateFrom"]').val(picker.startDate.format('YYYY-MM-DD'));
        $('input[name="dateTo"]').val(picker.endDate.format('YYYY-MM-DD'));
    });

java에서는 dateFormat을 YYYY-MM-dd라고 적어주지만, js에서 동일하게 적었더니 dd에서 일자가 아닌 요일이 불러와졌다. js에서는 YYYY-MM-DD로 적어야 하는 것 같다.

프론트는 정말,,,, 어려운것 여튼 타임리프를 처음 써보면서 사실 문법에 대한 학습도 없이 우선 만들면서 필요한 부분을 찾으면서 만들다 보니, 정리하지 않는다면 다 까먹을 것 같다는 생각이 들어서 글을 작성한다!

1. form태그

Thymeleaf에서는 백엔드에서 값을 받고 전달하려면, th:를 써줘야한다. form태그는 submit(제출)하는 값이 있을 때 사용하는 태그인데, @PathVarible을 쓰면 Long타입이 String 타입으로 전달되서 타입이 맞지 않는다는 예외가 나왔다. 그러고 겨우 타입을 맞춰놓으니, ${patient.id}라는 내용이 그대로 전달이 되고 해당하는 값이 전달되지 않았다.

th:action="@{'/' + ${patient.id} + '/income/create'}"
처음에는 위에와 같이 작성했는데, 읽혀지지가 않았고 구글링을 한참하면서 해결해본 결과, 아래와 같은 방식으로 작성하면 정상적으로 읽히는 것을 확인했다.

th:action="@{/{pId}/income/create(pId=${patient.id})}

그런데 웃긴?신기한 것은 href는 위에와 같이 작성해도 정상적으로 읽힌다.......!

또한, 재고는 로우가 계속 생기는 방식으로 만들겠지만, 실질적으로 재고를 조회할 때는 한 품목당 현재 재고가 어떻게 되는지 조회를 해야하는데, 값을 + -로 애초에 받아서 계산을 해서 뿌려줘야할지, 아니면 처음 설계한 대로 isBuy에 값을 통해서 +-를 곱해서 계산해야하는지도 고민이 필요하다.

그리고, 클라이언트의 요구사항이 발생했닿ㅎㅎㅎㅎㅎ 한의원 이전으로 이제 예약 시스템을 도입하려고 하는데, 20분에 1명씩 예약을 원하고 점심시간 전 1시간과 마감 1시간 전부터는 예약을 받지 않도록 원하는 상황이다. 우선 네이버 예약을 찾아보니, 네이버의 경우 30분/1시간 단위로만 예약을 할 수 있게 되어있다.

내가 만들고 있는 기능을 실제로 사용할지는 모르겠지만, 프로그램이 완성되는 경우 프로그램을 구매하겠다는 의사를 밝혀주셔서(얼마나 주실랑가) 해당 기능을 추가해보기로 했다!

이제 백엔드 로직은 거의 마무리되는 단계인데, 프론트를 시작해야할지 OAuth와 문자 발송 기능을 만들어야할지 배포를 진행하는지, 우선 순위를 정하기가 어렵다...

이 것이 현재까지의 나의 상황!

빈이 많아지고 복잡해지면 ApplicationContext 생성에 적지 않은 시간이 걸릴 수 있다. ApplicationContext가 만들어질 때 모든 싱글톤 빈 오브젝트를 초기화하는데, 이 작업이 많은 시간이 소요된다. 이 문제를 해결하기 위해서 ApplicationContext를 static 레벨에 저장해두는 방법도 있지만, 스프링이 직접 제공하는 ApplicationContext 테스트 지원 기능을 사용하는 것이 편리하다.

테스트를 위한 애플리케이션 컨텍스트 관리

스프링 테스트 컨텍스트 프레임워크 적용

@Runwith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="/applicationContext.xml")
public class UserDaoTest {
    @Autowired
    private ApplicationContext context;

    @Before
    public void setUp() {
        this.dao = this.context.getBean("userDao", UserDao.class);
    }
}

context를 초기화해주는 코드는 없어서, 메소드에서 context를 사용하려면 NullPointerException이 발생하지만, 테스트에서는 아무런 문제가 발생하지 않는다.

여기서 더 간단하게는, UserDao를 주입받아서 사용할 수도 있다.

public class UserDaoTest {
    @Autowired
    UserDao dao;
}

DI와 테스트

DataSource의 구현 클래스를 바꾸지 않고, DB 커넥션의 정보를 바꾸 일이 없는데도, 굳이 인터페이스를 사용해서 DI를 주입해주는 방식을 사용해야 할까? (매일 고민하는 부분...)

1. 소프트웨어 개발에서 절대로 바뀌지 않는 것은 없기 때문에, 클래스 대신 인터페이스를 사용하고 new를 이용해서 생성하는 대신 DI를 통해 주입받게 하는 것은 아주 단순하고 쉬운 작업이다. 당장에는 클래스를 바꿔서 사용할 계획이 없더라도 언젠가 변경이 필요한 상황이 닥친다면 수정에 들어가는 시간, 비용을 줄일 수 있다.
2. 클래스의 구현 방식은 바뀌지 않더라도 인터페이스를 두고 DI를 적용해두면 다른 차원의 서비스 기능을 도입할 수 있기 때문이다. 스프링의 AOP 기법을 적용하기 위해선 기본적으로 DI 적용이 필요하다.
3. 효율적인 테스트를 손쉽게 만들기 위해서라도 DI를 적용해야 한다. DI는 테스트가 작은 단위의 대상에 대해 독립적으로 만들어지고 실행되기 하는데 중요한 역할을 한다.

테스트 코드에 의한 DI

테스트를 하면서 실제 운영되는 DB에 사용자 정보를 수정하거나 삭제하는 일이 벌어진다면??? 그러지 않으려면, @DirtiesContext로 ApplicationContext 구성이나 상태를 변경한다는 것을 알리고, DataSource의 정보를 다시 생성해서 사용하는 방법이 있다. 하지만, 이미 주입받은 것을 다시 덮어쓰기?하는 느낌으로 별도의 DI를 설정하는 방법이 있다.

테스트를 위한 별도의 DI 설정

책에서는 xml 파일을 별도로 두고, @ContextConfiguration으로 설정 파일의 정보를 알려주는 방식을 알려주고 있지만, 나는 properties 파일을 적용하고 있어서 찾아보았다.

https://stackoverflow.com/questions/32974432/spring-junit-testing-properties-file

배포용과 로컬 DB 정보를 별도로 두고, 설정해줬던 방법처럼 application-test.properties 파일을 만들고 경로 지정하려고 하며 검색해보니, 스택오버플로우에 좋은 답변이 있다.

test에서는 굳이 파일명을 다르게 할 필요가 없이, 경로를 main, test 위치만 다르게 하여서 @PropertySource("classpath:application.properties ")로 경로를 알려주는 방법이 있었다.

컨테이너 없는 DI 테스트

public class UserDaoTest {
    UserDao dao;

    @Before
    public void setUp() {
        dao = new UserDao();
        DataSource dataSource = new SingleConnectionDataSource("jdbc:mysql://localhost/testdb", "spring", "book", true);
        dao.setDataSource(dataSource);
    }

}

@Autowired를 하지 않아도 되고, 직접 오브젝트 생성, 관계 설정을 해준다. Autowired는 하나만 주입 시에는 생략해도, 필드 주입이 가능하고,,, @Before 어노테이션으로 무조건 해당 메소드가 실행되니까 메소드 내부에서 생성을 해주는 방법이 가능한 것 같다.

학습 테스트

학습 테스트의 장점

1. 다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있다.
2. 학습 테스트 코드를 개발 중에 참고할 수 있다
3. 프레임워크나 제품을 업그레이드할 때 호환성 검증을 도와준다.
4. 테스트 작성에 대한 좋은 훈련이 된다.
5. 새로운 기술을 공부하는 과정이 즐거워진다.ㅎㅎㅎㅎ

그러면 단 건 조회의 dto을 list로 받아오고 그 외의 값을 가지고 와야하는데, 한 번에 db에서 모든 값을 계산해서 가지고 오는 것이 성능적으로 좋을 것 같다는 생각이 들었다.

select count(case when is_acupuncture = 1 then 0 end) as acupunctureCase,
count(case when is_acupuncture = 0 then 0 end) as medicineCase,
count(*) as totalCase,
sum(if(is_acupuncture = 1, amount, 0)) as acupunctureAmount,
sum(if(is_acupuncture = 0, amount, 0)) as medicineAmount,
sum(amount) as totalAmount
from income
where income.patient_id = 4;

우선 MySQLWorkbench에서 쿼리문을 작성해서 날려보고 이를 적용해서 repository에 메소드를 생성하려고 한다.

총합이나 전체 카운트의 경우, 어렵지 않았다. 그리고, 조건을 걸어서 카운트 하는 경우도 어렵지 않았지만 조건을 걸어서 합을 구하는 것은 해결하지 못하고 있다..!

구글링을 아무리 해봐도 유사한 경우도 나오지 않는다ㅠㅠㅠ 합계를 구해야하는 컬럼과 조건을 체크해야하는 컬럼이 다르기 때문에 문제가 발생하는 것인데 해결되기 전에 미리 정리해두는 것이 좋을 것 같아 기록중..🫠

1. 메소드를 두 개 혹은 세 개로 쪼개서, count하는 메소드와 매출액 합계를 내는 메소드를 만들고 나중에 이를 합치는 방법도 있다. 하지만, 이런 식으로 만들 경우 불필요하게 db에 들락날락 거리는 느낌이 든다.

2. 원래 설계대로 테이블을 약 환자와 침 환자를 다시 나누고 집계하는 방식도 있을 것 같다. 오히려 join으로는 sum을 구하기 쉬울 것 같고, 단순히 합계의 경우 각각 구한 값을 dto단에서 더해서 리턴해줄 수 도 있을 것 같다. 하지만, 미수금 또는 결제 수단에 따른 합계를 계산한다고 하면 결국 똑같은 문제가 발생할 것 같다. (각 테이블 내에서 카드결제 집계, 현금결제 집계를 하면 동일한 문제 직면)

CaseBuilder와 이용해서 메소드를 만들었는데, InvalidDataAccessApiUsageException가 발생했다.

ExpressionUtils를 이용해서 만든 메소드는 값이 제대로 추출되지 않는다.

너무 이 기능에 많은 시간을 할애하고 있어서 우회해서 처리하는 방식을 생각해보니, 어차피 List로 가지고 오는 값이 있으니까 그 값을 stream으로 더하거나 카운트할 수 있다는 생각이 들었다.

@RequiredArgsConstructor
@Getter
@Builder
public class IncomeSummeryResponseDTO {

    private final long totalCase;
    private final long acupunctureCase;
    private final long medicineCase;

    private final long totalAmount;
    private final long acupunctureAmount;
    private final long medicineAmount;

    private final List<IncomeResponseDTO> incomeResponseDTOS;

    public static IncomeSummeryResponseDTO from(List<IncomeResponseDTO> incomeResponseDTOS) {

        long medicineAmount = incomeResponseDTOS.stream()
                .filter(incomeResponseDTO -> incomeResponseDTO.getIsAcupuncture() == false)
                .mapToLong(incomeResponseDTO -> incomeResponseDTO.getAmount())
                .sum();
        long acupunctureAmount = incomeResponseDTOS.stream()
                .filter(incomeResponseDTO -> incomeResponseDTO.getIsAcupuncture() == true)
                .mapToLong(incomeResponseDTO -> incomeResponseDTO.getAmount())
                .sum();
        long medicineCase = incomeResponseDTOS.stream()
                .filter(incomeResponseDTO -> incomeResponseDTO.getIsAcupuncture() == false)
                .count();

        long acupunctureCase = incomeResponseDTOS.stream()
                .filter(incomeResponseDTO -> incomeResponseDTO.getIsAcupuncture() == true)
                .count();

        return IncomeSummeryResponseDTO.builder()
                .incomeResponseDTOS(incomeResponseDTOS)
                .medicineAmount(medicineAmount)
                .acupunctureAmount(acupunctureAmount)
                .totalAmount(medicineAmount + acupunctureAmount)
                .medicineCase(medicineCase)
                .acupunctureCase(acupunctureCase)
                .totalCase(medicineCase + acupunctureCase)
                .build();
    }
}

List로 가지고 온 값이니까, DB에는 다시 들리지 않아도 되지만 찜찜한 기분이 든다....😭😭😭

stream으로 연산하는 것과 repository에 다시 접근해서 count,sum 하는 방법 중에서 어떤 것이 메모리나 시간적으로 효율적일지 알아볼 필요가 있다..!

@Entity
@Table(name = "patient", uniqueConstraints = { @UniqueConstraint(name = "UniqueNameAndBirthday", columnNames = { "name", "birthday" }) })
public class Patient {

    @OneToMany(mappedBy = "patient", fetch = FetchType.LAZY)
    private List<Income> incomes = new ArrayList<>();
}

일대다 관계인 환자 테이블에는 fetch를 LAZY로 추가해줬다.

@Entity
@Table(name = "income")
public class Income {

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumns(value = {
            @JoinColumn(name = "patient_id", referencedColumnName = "id"),
            @JoinColumn(name = "patient_name", referencedColumnName = "name"),
            @JoinColumn(name = "patient_birthday", referencedColumnName = "birthday")
    } , foreignKey = @ForeignKey(value = ConstraintMode.NO_CONSTRAINT))
    private Patient patient;
}

다대일 관계인 매출 테이블에는 JoinColumns에 정보를 추가해줬다.

다시 생각하니, 복합키로 매핑할 필요가 없고 DTO에서만 이름, 생일을 받아서 충분히 처리가 가능한 상황이다.. 심지어 매핑한 부분으로 로직이 건들여지는 부분도 없어...!! 그래서 코드에서는 이 내용을 삭제했지만, 좋은 학습이였다~~

참고한 블로그 및 사이트 https://www.baeldung.com/jpa-join-column https://minssan9.tistory.com/m/42

봉프가 일반적으로 병원에 갔을 때, 생일과 이름으로 대조해보지 않느냐며 아이디어를 제공해줘서 이름과 생일을 unique 제약조건으로 만들어야겠다고 생각했다.

그리고 pId라고 명시한, 병원에서 이미 가지고 있던 차트번호의 경우 자동 생성되는 patient의 id와 혼돈이 있어서 chartId로 네이밍을 변경했다.

여튼 제약조건 설정은 엄청 간단하다..!

@Table 어노테이션에 추가로 명시

@Table(uniqueConstraints = { @UniqueConstraint(name = "UniqueNumberAndStatus", columnNames = { "personNumber", "isActive" }) })

baeldung에서 확인한 내용인데, 간단하게 UniqueConstraint 어노테이션을 추가하고, 제약조건의 이름과 제약조건에 해당하는 컬럼 이름을 명시하면 된다.

하나의 엔티티에 레포지토리를 2개두고, querydsl을 사용하는 클래스에서는 메소드를 구현해서 사용을 했다. querydsl 관련한 config 클래스도 만들어서 테스트를 한 후, 정상적으로 작동하는 것을 확인했지만 자꾸 nullpointerException이 뜬다..!!!! patient를 못찾아서 오류가 생긴거라고 생각하고, 정보가 제대로 전달되는지 확인했는데 거기가 문제가 아니였다. 문제가 뭔지도 찾는데 한참 걸렸는데ㅠㅠ 문제는 JPAQueryFactory!! 그니까 레포지토리 자체를 찾지 못하는 문제였다..

우선 레포지토리는 당연하겠지만, 한 엔티티에 하나씩 사용이 가능하다. 나는 두 개의 레포지토리에 모두 어노테이션을 붙여서 못 읽은 것이라고 생각하고 JpaRepository를 상속받은 기본 인터페이스는 주석 처리했지만, 레포지토리의 메소드를 읽어 오지 못했다.

querydsl를 설정하는 방법은 총 3가지가 있다고 하는데, 나는 그 중에 가장 간단한 방법인 config 파일을 만들고, 레포지토리 내부에서 JPAQueryFactory를 선언해서 사용하는 방법으로 코드를 작성했다. 근데 그 부분에서 문제가 있었던 것인지 레포에 아예 접근을 하지 못했다.

그래서, RepositoySupport를 사용하는 방법과 RepositoryCustom, RepositoryImpl을 사용하는 방법 두 가지 모두 테스트해보았고 정상 작동하는 것을 확인했다.

그러면 내가 만들어서 동작한 코드에 대해서 살펴보겠다.

우선 공통적으로는 JPAQueryFactory의 빈 등록이 필요하다. 두 가지 모두 config 클래스를 만들어 준다. 설정을 변경하면서, 클래스 자체를 주석처리 해봤는데, 빈을 찾을 수 없다고 하며 컴파일 과정에서 실행이 실패되었다.

import com.querydsl.jpa.impl.JPAQueryFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Configuration
public class QuerydslConfiguration {

    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

1. QuerydslRepositorySupport

장점

• 스프링 데이터가 제공하는 페이징을 Querydsl로 편리하게 변환 가능(단, Sort는 오류 발생) : getQuerydsl().applyPagination()

• from()으로 시작 가능

• EntityManager 제공

  한계

• Querydsl 3.x 버전을 대상으로 만들었다.

• Querydsl 4.x에서 나온 JPAQueryFactory로 시작할 수 없어서 select로 시작할 수 없음

• QueryFactory를 제공하지 않음

• 스프링 데이터 Sort 기능이 정상 동작하지 않음

  @Repository
  public class IncomeQueryRepositorySupport extends QuerydslRepositorySupport {
  
    private final JPAQueryFactory queryFactory;
  
    public IncomeQueryRepositorySupport(JPAQueryFactory queryFactory) {
        super(Income.class);
        this.queryFactory = queryFactory;
    }
  
  

public Optional<Income> findLastVisitIncomeByPatient (Patient patient) {
    Income income = queryFactory.selectFrom(QIncome.income)
            .where(QIncome.income.patient.eq(patient))
            .orderBy(QIncome.income.date.desc())
            .fetchFirst();
    return Optional.ofNullable(income);
}

...

}

[이동욱님 블로그](https://jojoldu.tistory.com/372)를 참고해서 만들었고, 위에 코드는 내가 만든 support 클래스를 그대로 가지고 왔다.
QuerydslRepositorySupport를 상속받은 클래스를 레포지토리로 만들고,
생성자에서 JPAQueryFactory를 주입받아서 사용했다.
~~위에 한계에서는 JPAQueryFactory로 시작할 수 없어서 select문으로 사용이 불가능하다고 했는데, select로 시작해도 정상적으로 코드가 잘 돌아갔다.~~

이렇게 사용하면, JpaRepository를 상속받은 기본적인 인터페이스 레포지토리가 하나 더 필요하다.
save, delete 등은 해당 레포지토리로 사용하고, querydsl을 사용한 코드는 support 레포지토리에서 호출해서 사용하는 방식으로 쓰면 된다.

## 2. Custom, Impl, Repository
위의 방식을 사용할 경우, 2개의 레포지토리를 의존성으로 받아야 하는 단점이 있어서 
Custom Repository를 JpaRepository 상속 클래스에서 사용할 수 있도록 만들어봅니다.

### (1)custom interface 만들기

public interface IncomeRepositoryCustom {

public Long countVisitByPatient(Patient patient);

}

사용할 추상 메소드를 만들어준다.
### (2)Impl class 만들기

@RequiredArgsConstructor public class IncomeRepositoryImpl implements IncomeRepositoryCustom{

private final JPAQueryFactory queryFactory;

public Long countVisitByPatient(Patient patient) {
    return queryFactory.selectFrom(QIncome.income)
            .where(QIncome.income.patient.eq(patient))
            .fetchCount();
}

}

위에서 만든 인터페이스를 구현한 구현체 클래스를 만들어주고, 추상 메소드를 override한다.
JPAQueryFactory를 주입받는다.
### (3)Repository interface 만들기

@Repository public interface IncomeRepository extends JpaRepository<Income, Long>, IncomeRepositoryCustom {

}

``` JpaRepository, Custom 인터페이스를 상속하는 인터페이스를 만들고 @Repository 어노테이션을 붙여준다. 만약 페이징 처리가 필요하다면, QuerydslSupport도 상속하는 것 같다.

처음에는 파일을 많이 만들고 싶지 않아서 JPAQueryFactory를 필드 주입받아서 레포지토리 클래스를 만드는 방식으로 사용했는데, 원하는대로 작동이 하지 않아서 나머지 두 가지 방식을 사용해보았다.

첫 번째 방법도 결국 레포지토리 2개에 의존받는 것은 동일했고, 두 번째 방법은 파일(클래스/인터페이스)가 더 많이 생기는 것은 있지만 실질적으로 의존성으로 받는 레포지토리는 1개라는 점에 차이가 있었다.

가장 간단한 방법은 실패했지만, 정상적으로 작동한다면 해당 내용도 정리해서 추가해야지!!

테스트의 유용성

테스트란 결국 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인해서, 만든 코드를 확신할 수 있게 해주는 작업이다. 또한 테스트의 결과가 원하는 대로 나오지 않는 경우에는 코드나 설계에 결함이 있음을 알 수 있다. 이를 통해 코드의 결함을 제거해가는 작업, 일명 디버깅을 거치게 되고, 결국 최종적으로 테스트가 성공하면 모든 결함이 제거됐다는 확신을 얻을 수 있따.

웹 화면을 통해 값을 입력하고, 기능을 수행하고, 결과를 확인하는 방법은 가장 흔히 쓰이는 방법이지만, DAO에 대한 테스트로서는 단점이 너무 많다. DAO뿐만 아니라 서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어 기능을 다 만들고 나서야 테스트가 가능하다는 점이 가장 큰 문제이다. 테스트를 하는 중에 에러가 나거나 테스트가 실패했다면, 과연 어디에서 문제가 발생했는지를 찾아내야 하는 수고도 필요하다.

작은 단위의 테스트

작은 단위의 코드에 대해 테스트를 수행하는 것을 단위 테스트(unit test)라고 한다. 단위는 충분히 하나의 관심에 집중해서 효율적으로 테스트할 만한 범위의 단위라고 보면 되고, 일반적으로 단위는 작을수록 좋다. 테스트 중에 DB가 사용되면 단위 테스트가 아니라고 하기도 하는데, DB의 상태가 매번 달라지고, 테스트를 위해 DB를 특정 상태로 만들어줄 수 없다면 단위 테스트로서 가치가 없어지기 때문에, 그런 차원에서는 통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트가 아니라고 보기도 하는 것이다.

단위 테스트를 하는 이유는 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인받기 위해서다.

JUnit

Junit은 프레임워크로, 메인 메소드가 필요하지 않다.

JUnit 의 조건

• 메소드가 public으로 선언되어야 한다. (접근제어자는 생략하더라도, public으로 생성되는 것으로 알고 있음.)
• 메소드에 @Test라는 애노테이션을 붙여주어야 한다.

테스트 메소드에서 예외 상황이 발생할 수 있는 경우에는 애노테이션에 excepted 엘리먼트를 명시해주면 된다.

@Test(expected = EmptyResultAccessException.class)
public void getUserFailure() throws SQLException {
    ~~~
}

포괄적인 테스트

스프링의 창시자인 로드 존슨은 "항상 네거티브 테스트를 먼저 만들라"라는 조언을 했다고 한다. 테스트를 작성할 때는 부정적인 케이스를 먼저 만드는 습관을 들이는 것이 좋다. 존재하는 정보에 대한 확인을 하는 테스트도 좋지만, 존재하지 않는 객체에 대해서는 어떻게 반응할지를 먼저 결정하고, 이를 확인할 수 있는 테스트를 먼저 만들려고 한다면 예외적인 상황을 빠뜨리지 않는 꼼꼼한 개발이 가능하다.

TDD

TDD에서는 테스트 작성하고 이를 성공시키는 코드를 만드는 작업의 주기를 가능한 짧게 가져가도록 권장한다.

Annotation

@Before (=@BeforeEach)

모든 테스트 메소드가 실행되기 전에 각각 실행되는 메소드

@BeforeAll

테스트 클래스가 실행되었을 때 한 번 실행되는 메소드

@After (=@AfterEach)

모든 테스트 메소드가 실행된 후 각각 실행되는 메소드

@AfterAll

테스트 클래스가 끝나기 전에 마지막으로 한 번 실행되는 메소드

스프링의 기본적인 동작 원리가 모두 IoC 방식이라고 할 수 있지만, 스프링이 다른 프레임워크와 차별화돼서 제공해주는 기능은 의존관계 주입이라는 새로운 용어를 사용할 때 분명하게 드러난다. 그래서 초기에는 IoC컨테이너라고 불리던 스프링이 지금은 의존관계 주입 컨테이너, DI 컨테이너라고 더 많이 불린다고 한다.

제어의 역전은 쉽게 생각해서 내가 작성한 코드가 직접 제어의 흐름을 담당하지 않고, 그 제어권을 프레임워크가 담당하는 것이라고 이해하면 되는데 라이브러리와 프레임워크의 차이도 그렇게 이해하면 될 것 같다. 제어권을 코드가 가지고 있다면 라이브러리를 사용한 것, 제어권을 가지고 있지 않다면 프레임워크

스프링 컨테이너는 빈이 등록되는 컨테이너라고 생각하면 되는데, 빈은 어노테이션으로 자동 등록되고 거기서 ApplicationContext(BeanFactory)를 통해 빈을 꺼내서 사용할 수 있다.

이번 주 내내 프로젝트를 구현하면서, 인터페이스의 구현체를 만드는 것이 의미가 있는지 오히려 파일 자체를 하나 더 만들게 되니까 번거로운 작업이 아닌가 고민했다. 뭐 인터페이스를 상속받아서 구현하는 클래스가 다양한 경우(책에서는 N사, D사와 같은 경우)가 있을 수 있다지만, 솔루션을 만드는 경우도 아니라면 더욱 왜 그렇게까지 하는건지 이해가 안되었는데 의존관계가 여기의 실마리였다!

의존관계

클래스 A가 B에 의존하고 있음을 나타내는 UML 다이어그램이다. 의존한다는 것은 의존대상(B)가 변하면 그것이 A에 영향을 미친다는 것을 뜻한다. 대표적인 예는 A가 B에 정의된 메소드를 호출해서 사용하는 경우다. 만약 B에 새로운 메소드가 추가되거나 기존 메소드가 변경되면 A도 그에 따라서 수정해야 한다.

만약 클래스끼리 직접적인 의존관계가 아닌 클래스와 인터페이스간 의존관계가 있고, 인터페이스를 구현한 클래스를 사용한다면 구현체가 변경되거나 내부의 메소드에 변화가 생겨도 UserDao에는 영향을 주지 않는다. 이렇게 인터페이스에 대해서만 의존관계를 만들어두면 인터페이스 구현 클래스와의 관계는 느슨해지면서 변화에 영향을 덜 받는 상태가 된다. 결합도가 낮다고 설명할 수 있다.

의존관계 주입

주입이라는 건 외부에서 내부로 무엇인가를 넘겨줘야 하는 것인데, 자바에서 오브젝트에 무엇인가를 넣어준다는 개념은 메소드를 실행하면서 파라미터로 오브젝트의 레퍼런스를 전달해주는 방법뿐이다. 가장 손쉽게 사용할 수 있는 파라미터 전달이 가능한 메소드는 바로 생성자다.(p.116)

DI는 자신이 사용할 오브젝트에 대한 선택과 생성 제어권을 외부로 넘기고 자신은 수동적으로 주입받은 오브젝트를 사용한다는 점에서 IoC의 개념에 잘 들어맞는다. 스프링 컨테이너의 IoC는 주로 의존관계 주입 또는 DI라는 데 초점이 맞춰져 있다. 그래서 스프링을 IoC 컨테이너 외에도 DI 컨테이너 또는 DI 프레임워크라고 부르는 것이다.(p.117)

의존관계 검색(Dependency Lookup)과 주입

스프링에서는 의존관계 주입 이외에도 의존관계를 스스로 검색해서 이용하는 의존관계 검색(DL)도 있다. 의존관계 검색이 바로 스프링 컨테이너에서 getBean()을 통해서 빈을 찾아서 오브젝트를 가져오는 방법인데, 테스트 코드등을 작성할 때는 static 메소드인 main 메소드에서는 DI를 이용해서 오브젝트를 주입받을 방법이 없기 때문에 의존관계 검색을 사용해서 오브젝트를 가지고 와야 한다.

DI와 DL의 차이점은, DI를 원하는 오브젝트는 자기 자신도 컨테이너가 관리하는 빈으로 등록되어야 하고 DL의 경우에는 자기 자신은 빈으로 등록되어야 할 필요가 없다는 점이다.

메소드를 이용한 의존관계 주입

의존관계는 생성자, 수정자(setter), 메소드, 필드를 이용해서 주입이 가능하다. 수정자의 경우, 1개의 파라미터만 가질 수 있지만, 메소드를 통한 주입은 여러 파라미터를 가질 수 있다.

//수정자 메소드를 이용한 DI
public class UserDao {
    private ConnectionMaker connectionMaker;

    public void setConnectionMaker(ConnectionMaker connectionMaker) {
        this.connectionMaker = connectionMaker;
    }
}

EntityManager

EntityManager는 말 그대로, 엔티티를 관리하는 역할을 수행하는 클래스라고 한다. 엔티티 매니저는 내부에 영속성 컨텍스트(Persistence Context)를 두고 엔티티를 관리한다고 한다. 영속성은 JPA의 P....? 영속성 컨텍스트는 엔티티를 영구적으로 저장하는 환경이라고 하는데, 영속성이라는 단어는 봐도봐도 레이어를 그림으로 보더라도 와닿지는 않는다ㅠㅠ

JPAQueryFactory

CrudRepository & JpaRepository

JPA를 사용하더라도, CrudRepository만 사용했는데, JpaRepository가 있었다...! 역시 프로젝트를 구상하고 만들어가는 것이 그냥 개념 학습하는 것보다 더 많은 키워드를 접하고 학습하게 된다. 필요에 의해서 찾아보고 적용해보니까 그런 것 같다!!

여튼! JpaRepository도 결국 CrudRepository가 부모인 인터페이스다. 더 하위로 들어가면, JpaRepositoryImplementation<T,ID>가 자녀고, QuerydslJpaRepository<T,ID extends Serializable>가 자녀의 자녀다. 구현체같은 이름을 가진 JpaRepositoryImplementation<T,ID>는 인터페이스고 QuerydslJpaRepository<T,ID extends Serializable>는 인터페이스가 아닌 클래스다.

전부 그려보자면 이런 모양이라고 할 수 있다.

결국 두 인터페이스의 차이는 페이징, 소팅 작업에 대한 기능의 추가라고 이해해도 무방할 것 같다. CrudRepository는 Iteratable을 리턴했으면, JpaRepository는 List를 리턴하는 차이도 있다.

이전까지는 페이징 처리하는 작업이 없어서 CrudRepository로 충분했지만, 지금 프로젝트에는 JpaRepository를 적용해서 사용해야겠다.

날짜는 income중에서도 해당 환자의 가장 최근 방문일을 찾아서, 그 날짜로 반영되어야 한다.

select date from income
where patient_id = 11
order by date DESC limit 1;

간단하게는 limit를 걸어서 날짜를 추출할 수 있다! 하지만 쿼리문을 반영하기 위해서는? 쿼리문 반영은 여기서 끝일 것인가????

그래서 querydsl을 학습하고 도입해보기로 했다. 부랴부랴 인프런 강의 결제!ㅋㅋㅋㅋㅋㅋ

강의를 순서대로 따라하되, 시간이 부족하니 내 프로젝트에 바로 반영해보려고 한다.

build.gradle에 plugins, dependencies 및 querdsl의 디렉토리 정보 등을 추가해준다. $buildDir/generated/querydsl은 Q클래스가 생성되는 위치다.

그리고 other > compileQuerydsl을 실행하면 Q클래스가 생성된 것을 확인할 수 있다.

git에는 Q클래스를 올리면 안된다고 한다!! 일단은 설정 완료!!!!!!!