언제 for을 사용하고, 언제 while을 사용하느냐가 궁금하실 겁니다.
while은 조건밖에 없기 때문에 몇 번 반복될 지 모를 때 주로 사용되고,
for문은 반복 횟수를 정할 수 있기 때문에 몇 번 반복될 지 알 때 주로 사용됩니다.
복습반 부시기
인증(Authentication) vs 인가(Authorization)
Authentication
Auth 별거 없다.
인증이라는 의미임
일반적으로 사이트 로그인 할 때
어디 들어갈 때 신분증 검사 하는 거라고 보면 된다.
Authorization
인가(Authorization)는
인증된 사용자가 특정 리소스에 접근 하거나 특정 작업 수행할 수 있는지
권한 검증하는 것임.
- auth 미들웨어를 통해 구현할 것 = 인가(Authorization)
Validation 유효성 검사
검증과 인증은 또 무슨 차이인가?
먼저 이야기 할 것이 있다
위에 auth 에서 신분증 검사 한다 그랬는데, 또 이렇게 말할 수 있다.
Identification 식별
: 신원을 확인하는 것이다. 너 누구야? 보다 그냥 민증 제시하면 되는 것이다.
verification 검증
: 정말 너가 주장하는 너가 맞음? 검증해본다는 것이다. 신뢰할 수 있는지.
Authentication 인증
: 우리 골프장 회원인지, 헬스장 회원인지, 이전에 액세스한 사람과 같은지
식별되고 검증된 회원이 가입이 되어서 그 회원이 맞는지 인증한다는 것이다.
비밀번호 보안 질문이나, 얼굴 인식이나 암호화 키나 ... 등
귀하가 본인 맞슴네까? 하는거다.
쨌든.
validation(검증)해서 유효성이 있는지, 서버로 전송하기 전에 검증하는 단계를 이야기한다.
Layered Architecture Pattern
1. 프레젠테이션 계층 ->대표적으로 컨트롤러
- 하위계층의 예외를 처리함.
- 클라이언트가 전달한 데이터 유효성 검증.
- 서버에서 처리된 결과 반환
- 클라이언트의 요청(Request)을 수신합니다.
- 요청(Request)에 들어온 데이터 및 내용을 검증합니다.
- 서버에서 수행된 결과를 클라이언트에게 반환(Response)합니다.
2. 비즈니스 로직 계층 -> 서비스 계층
아키텍처의 가장 핵심적인 비즈니스 로직을 수행
클라이언트가 원하는 요구사항을 구현하는 계층
프레젠테이션, 데이터 액세스 계층 사이 중간다리 역할
-> 서로 다른 두 계층이 직접 통신하지 않게 함
사용자의 요구사항 처리하는 실세
-> 현업에서는 서비스 코드가 계속 확장되는 문제가 발생할 수 있음.
서비스 계층의 장단점
서비스 계층의 장점
- 사용자의 **유즈 케이스(Use Case)**와 **워크플로우(Workflow)**를 명확히 정의하고 이해할 수 있도록 도와줍니다.
- 비즈니스 로직이 API 뒤에 숨겨져 있으므로, 서비스 계층의 코드를 자유롭게 수정하거나 리팩터링할 수 있습니다.
- 저장소 패턴(Repository Pattern) 및 **가짜 저장소(Fake Repository)**와 조합하면 높은 수준의 테스트를 작성할 수 있습니다.
서비스 계층의 단점
- 서비스 계층 또한 다른 추상화 계층이므로, 잘못 사용하면 코드의 복잡성을 증가시킬 수 있습니다.
- 한 서비스 계층이 다른 서비스 계층에 의존하는 경우, 의존성 관리가 복잡해질 수 있습니다.
- 서비스 계층에 너무 많은 기능을 넣으면 **빈약한 도메인 모델(Anemic Domain Model)**과 같은 안티 패턴이 생길 수 있습니다.
이번 **서비스 계층(Service Layer)**에서 PostsService 클래스가
PostsRepository의 findAllPosts, createPost 메서드를 호출하는 것을 확인할 수 있는데요,
해당 코드는 서비스가 비즈니스 로직을 수행하는 데 필요한 데이터를
- *저장소 계층(Repository Layer)**에게 요청하여 가져오는 것을 확인 할 수 있습니다.
또한, 서비스 계층에서는 return posts.map(post => {}); 와 같이 데이터를 가공하는 작업이 이루어집니다.
만약, 저장소 계층에서 받은 데이터를 그대로 클라이언트에게 전달한다면,
사용자의 비밀번호와 같은 민감한 정보까지 노출되는 보안 문제가 발생하여,
서버의 보안성이 떨어지는 결과를 낳게된답니다.
저장소 계층
데이터 액세스 계층이라고도 한다.
저장소 계층의 장점
- 데이터 모델과 데이터 처리 인프라에 대한 사항을 분리했기 때문에 **단위 테스트(Unit test)**를 위한 **가짜 저장소(Mock Repository)**를 쉽게 만들 수 있습니다.
- 도메인 모델을 미리 작성하여, 처리해야 할 비즈니스 문제에 더 잘 집중할 수 있게 됩니다.
- 객체를 테이블에 매핑하는 과정을 원하는 대로 제어할 수 있어서 DB 스키마를 단순화할 수 있다.
- 저장소 계층에 ORM을 사용하면 필요할 때 MySQL과 Postgres와 같은 다른 데이터베이스로 쉽게 전환할 수 있습니다.
저장소 계층의 단점
- 저장소 계층이 없더라도 ORM은 모델과 저장소의 결합도를 충분히 완화시켜 줄 수 있습니다.
- → ORM이 없을 때 대부분의 코드는 Raw Query로 작성되어 있기 때문입니다.
- ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모됩니다.
- → 여기서 설명하는 ORM은 저희가 이전에 사용한 Prisma와 같은 라이브러리를 말합니다.
