TIL-19 스프링 특강 3회차 개념 0628

3계층으로 나누는 이유

SRP 단일 책임 원칙으로 인해

컨트롤러는 라우터의 역할, 서비스는 비즈니스로직, 레포지토리는 데이터관련의 역할만 맡는다.

 

싱글톤패턴

객체를 한개만 생성하여 공유하여 사용해 코드 재사용성을 높인다.

 

무상태성

스프링에서는 일반적으로 무상태성을 지향한다.

DTO를 제외하고 객체를 만드는 행위를 상태를 유지한다라고 표현한다.

서비스단, 컨트롤러단에서 new Bean하여 객체를 생성하는것을 하지 말아야 한다.

재 사용할수 있게끔 해야한다.

RepositoryDto,Entity, new Entity()..생성하는것은 Dto만 존재해야한다.

 

가비지 컬렉션

사용하지않는 객체가 있다면 자연적으로 소멸한다.

 

OCP

확장에는 열려있고 변경에는 닫혀있다.

메모레포지토리가 변경이되더라도 서비스계층은 영향을 받지않게끔 설계한다.

예를들어 같은 인터페이스를 구현한 레포지토리라면 멤버변수와 생성자만을 변경해 추가 코드수정없이 레포지토리를 갈아끼울 수 있다.

 

public static final int STANDARD = 3

스택과 힙영역 static같은 경우도 어떻게 보면 빈이라고도 할 수 있다. 선언하면 힙영역으로 가게 된다. 힙 영역은 만들어 놓고 재사용할 수 있는 메모리 영역이다

 

제어의 역전

레포지토리에서 주입해서 서비스로 간다. 서비스에서 주입해서 컨트롤러로 간다. 

new 해서 객체를 직접 생성하지 않는다.

 

 

DB-

jdbctemplate의 preparedstatement도 결국 객체를 매번 생성하기 때문에 리소스 관리가 효율적이지 못하다.

코드가 복잡하다.

sql에 의존적이어서 변경에 취약하다.

 

ORM

객체와 관계의 맵핑