1번

DI.

솔직히 DI 이거 굳이 DI도구 쓰지 않고

자기가 직접 main에서 재조합해서 인자로 명시해서 전달해줘도 됨.

근데

주입을, 설정파일손봐서 변경할래
코드만져서 변경할래?

프로파일링은?

프로파일링은!!!

하면 여기서부터

아, DI는 필요하다 느끼게 돼.



2번

상속(오버라이딩) ㅡ 프록시 ㅡ AOP

이 세가지가 모두 같은 대상을 지칭하는데

설명하기쉽게 프록시의 대상을 서비스레이어로만 한정시키면

우리가 선언한 서비스클래스를 직접 사용하지 않고
다른 부가기능을 결합해서
프록시로 만들어서 빈을 형성함.

즉 우리가 ~타입 으로 생성한 빈은
사실 해당타입이 아닌, 해당타입의 자식타입이다.

프록시다.

이 개념도 상당히 유용해

우리가 다루는 빈은 죄다
우리가 선언한 클래스세팅 이외에

스프링 어노테이션을 위시한 추가기능이 덧입혀지고 의존성주입도 들어가니

이렇게 좋은 도구가 있을 수가.



근데 이게 좋다는걸 깨닫기 위해선

일단

톰캣과 (DI/AOP) 를 분할해서 생각할수 있어야함.

예를들면 node진영의 express는 DI나 프록시개념이 없는 상태의 퓨어한 WAS인데

이 레이어를 구분해야돼


근데 우리 취준교육의 문제점이

자바떼고 스프링처음오면,
WAS부터 할 차례라
스프링 처음보고 놀라는건

GetMapping
PosyMapping같은 라우팅개념.

근데 라우팅은 진짜... 스프링의 핵심이 아니거든.

스프링 뭐하는데? 했을때 GetMapping이나
컨트롤러가 떠오르면 안됨.

DI와 AOP고

주된 관심사는 라우터/컨트롤러

측이 아니라

AOP/서비스 측에 있어야 한다는것


나같은경우는

하스켈로

DI나 상속 없는 상태에서
프로파일링과 오버라이딩을 구현해봤고
커넥션같은것도 DI없이 직접 main에서 형성하고 명시적 전달해서

인증 인가, 웹소켓 grpc 적용해봄

심지어 전역변수라는 야매가 아예 원천적으로 불가능한 하스켈이라서

저장공간의 선언과 전달 또한 명시해줬음.


그러다가 클로저와서

이제 스프링에서 썼던 기능들을 하나하나 재조합해나가고있는데

워어어우후...이거 참 ㅎㅅㅎ

여튼 난 긍까 뭐 비유를 하자면

express 위에다가 스프링기능을 다만들어버렸다,

먼저 DI를 얹고

DI콤포넌트를 통해 프로파일링과 오버라이딩을 진행하고

그 위에 DI로 통합된 다양한 라이브러리를통해

DB 커넥션을 콤포넌트화
웹소켓 라우터를 콤포넌트화

아 ㅇㅇ

웹서버와 웹서버라우터 웹서버 핸들러또한 DI콤포넌트화되어있음

쿠키세션스토리지도 컴포넌트화

스케쥴러

캐쉬

그 과정에서 사용되는 시리얼/디시리얼라이저

그리고  각종 미들웨어를 통한 에러핸들링.