Nest.js 로 간다 #20220329

강력한 결합 : 무지성 new new new.. ..?

강한 결합의 경우 매번 새로운 선언을 하게 되므로 메모리 부담이 큽니다. 휘발성 메모리의 경우 늘 용량 부족에 시달리는 부분이라 최대한 부담을 덜어주는 것이 좋습니다. 디스크라면 비휘발성이니 보다 낫겠지만.. 느리니까..

그리고 객체의 결합이 강하다는 것은 다른 클래스와의 융화성이 떨어진다는 뜻이기도 합니다. 따라서 보다 느슨한 결합을 추구하게 됩니다.

Loose Coupling : How to

유지 보수성을 보다 더 끌어올릴 수 있습니다. 기존 기능을 수정하거나 확장하더라도 유연한 대처가 가능하다는 말이기도 합니다. 선언을 한번 하게 될 index.js 에서 선언하고, 컨트롤러에서 컨스트럭터를 이용해서 그 값을 받아오는 것입니다.

싱글톤 패턴 이라고 합니다

선언하는 놈 따로, 쓰는 놈 따로

이렇게 하면 익스포트 임포트 지옥과 멀어질 수 있습니다. 순환 참조같은 문제도 미리 방지 할 수 있겠습니다.

거기다 추후에 변경사항이 있더라도, 컨스트럭터를 통해 index.js 에서 파라미터만 바꿔서 넣어주면 알아서 변경이 되게 됩니다.

DI

Dependency Injection, 의존성 주입.

이러한 과정들은 본래 개발자가 신경쓰면서 관리하고 제어하는 것이지만, 이제 nest가 제어를 하게 됩니다. 이것을 IoC : Inversion of Controll 이라고 합니다.

제어의 역전

뭔가 존나 쎈 기술명 같네요.

따라서 이제 Nestjs를 쓰게 된다면, 싱글톤 패턴을 기본으로, this. 을 주구장창 하게 됩니다.

그러나 의존성 주입을 한다고 하더라도 싱글톤 패턴을 자동으로 따르게 된다는 것은 아닙니다.

왜냐면 싱글톤 패턴의 요점은 코드의 재사용성을 최대한 높이는 것이기 때문이죠.

의존성 주입을 한다고 메인 파일에서 새로운 선언을 이름 바꿔가며 계속 한다면 싱글톤 패턴과는 거리가 있습니다.

프레임워크

이러한 Nest의 역할은 

• Java - Spring
• python - Django
• node - Nest

이라고 볼 수 있습니다. 공통점은 전부 DI 형태를 추구하는 프레임워크라는 점입니다. (쟝고는 아직 독립적인 DI 프레임워크는 아니지만 몇가지 라이브러리를 추가함으로서 비슷하게 구현 가능합니다)

Nest를 설치하기 앞서

일단 그 구조와 내가 빼앗기게 될 제어권에 대한 개념을 확실히 알고 넘어가야 합니다. 안그러면 미아가 될겁니다.

선언식 함수와 화살표 함수의 차이도 알아야 합니다. 일반 선언식 함수로 선언할 경우, this. 가 호출한 객체와 바인딩되어버려 클래스 안에 주입해놓은 생성자로 주입한 목표를 찾지 못합니다. 따라서 화살표함수를 써야 this. 가 함수를 선언할 때의 상위 스코프를 볼 수 있습니다.

설치하면

이런게 생긴다

놀라울 정도로 뭔가 빡빡하게 설치된다.