nest cli로 시작
nest new 프로젝트 명
main.ts가 모든 것의 시작
module은 app.module은 root module임(애플리케이션의 일부 1기능을 한다고 생각하면 됨. LOGIN등)
CONTROLLER(URL을 가져와서 함수 실행, EXPRESS ROUTER과 유사), PROVIDER(
SERVICE : BUSINESS로직을 담당함.
@usepipe
@usegard
같은 여러 데코레이터를 막 써도, 순서를 알아서 잘 지켜 줌.
OOP, FP, FRP(functional reactive programming)
main.ts에서
application을 bootstrap하는 비동기 함수가 있음.
nestFactory가 nest 어플리케이션 instance를 만들기 위해 제공한 함수이다.
nestfactory의 static method중 create는 INestApplication interface를 충족하는 어플리케이션 객체를 반환한다.
컨트롤러에서 쓸 수 있는 데코레이터(매개변수)
@Request(), @Req() req
@Response(), @Res()* res
@Next() next
@Session() req.session
@Param(key?: string) req.params / req.params[key]
@Body(key?: string) req.body / req.body[key]
@Query(key?: string) req.query / req.query[key]
@Headers(name?: string) req.headers / req.headers[name]
@Ip() req.ip
@HostParam() req.hosts
의존성
의존성 : service A 가 service B에 강하게 의존한다면 B가 변경되면 A가 컴파일이 되지 않거나, 동작에 오류가 생길 수 있다. 이 관계는 A를 재사용하기 어렵게 된다. 그렇기에 A는 component/service가 될 수 없다. component(소스코드의 수정 없이 다른 프로젝트에 재사용 가능한 모듈)
class의 의존 관계가 A=>B=>C인 여러 중첩관계는 의존성 부패라고 한다.
이런 의존성 부패를 없애기 위한 것이 DIP. dependency inversion principle 이다.
고차원 보듈은 저차원 모듈에 의존하지 말고, 추상화된 것에 의존해야 한다. 추상화된 것은 구체화된 것에 의존하면 안된다.
단순히 상속만 한다고 모든 의존성 부패가 해결 될까? 상속 관계로 다 처리를 한다고 쳐도 생기는 문제는
let switchHandler:SwitchBtnInterface=Button();
같은 느낌으로 가져간다고 했을 때 클래스에 다시 의존하게 되는 문제가 발생한다. 그러면 다시 재사용성이 떨어지는 문제가 발생하는데, 이를 Factory.getObject()같은 느낌으로 다시 한 번 의존성을 관리해줄 수 있다.
그런데 이제 클래스 밖으로 나가서 보면 블래스 외부에서 Factory나 class를
let switch=switchGenerator(Factory)
main 단위에서 담당하게 되는 되게 이상한 현상이 생긴다.
이를 해결하기 위해 Container를 하나 중간에 두어서 Main=>Container =>button, button ...=> 다음 작업 순으로 처리하는 것으로 조금 더 재사용성을 높일 수 있다.
이를 보면 client 쪽에서 모든 것을 제어하는 구조가 되는데, 이를 제어의 역전 IoC(inverson of Control)라고 한다. 단순한 factory와의 차이는 factory는 object를 생성하는 assembler이고, IoC Controller는 제어의 역전 개념이 적용되어야 한다.
injectable 이란? 생성자 기반의 의존성 주입. 특정 인스턴스를 클래스에 주입하고 싶을 때 사용할 수 있다.
제어 역전 기법에 해당.
의존성 주입을 해야하는 이유 :
1. 단위 테스트가 쉬워진다
2. 코드의 재활용 성을 높인다.
3. 객체간의 의존성을 줄이거나 없앨 수 있다.
4. 객체간의 결합도를 낮추면서 유연한 코드를 작성할 수 있다.
의존성 주입이란 spring의 기준에서는 이렇다.
1. 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 인터페이스만 의존하고 있어야 한다.
2. 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
3. 의존 관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공해줌으로써 만들어진다.
swagger :
1. api 디자인
2. api development
3. api documentation
4. api testing
5. standardize
