2021.07.30 기록장

ToDo

• 알고리즘 2문제
• 책 읽기
• 토비의 스프링

Done

• 토비의 스프링

Weekly goal

• 책 읽기
• 토비 스프링 코딩
• 북마크 보기

토비의 스프링

 

784p.

3 계층 아키텍처

책임과 성격을 다른 것을 그룹으로 만들어 분리해 두는 것을 계층형 아키텍처라고 한다.

 

스프링이라면 프레젠테이션 계층은 SpringMVC로 구현하고 서비스는 POJO로 데이터 액세스 계층은 JDBC 등 알아서.

 

서비스 계층은 DAO 계층과 소통의 자주 한다. 하지만 무조건 저들과 같이 일해야 서비스 계층이다 라고 말할 수는 없다.

서버나 시스템 레벨에서 제공하는 기능을 쓰기도 하기 때문이다. 메일 또는 메시징 서비스를 쓰는 것을 예로 들 수 있다.

 

서비스는 기반 서비스(트랜잭션, 보안, 메일, 메시징, 스케줄링..) 등에 종속되면 안 된다. 인터페이스로 접근을 해서 종속성을 제거해야 한다.

 

789p.

각 계층은 자신의 계층의 책임에만 충실해야 한다.

데이터 액세스 계층은 데이터 액세스에 관한 모든 것을 스스로 해결해야 한다.  DAO에서 ResultSet으로 반환을 하게 된다면 서비스는 알 필요가 없는 DAO의 동작 방법을 알게 된다. 만약 ResultSet에서 방법이 바뀐다면 서비스 계층까지 바뀌어야 하는 문제가 생긴다.

 

위와 같은 이유는 데이터 액세스 계층 -> 서비스 계층의 문제였다면 같은 이유로 프레젠테이션 계층 -> 서비스 계층의 문제로 자주 보이는 것은 HttpServletRequest를 넘겨주는 것이다. 이는  계층을 넘어서 service에게 전해주는 것이다.

service는 웹 기능에 종속적이게 된다. 나중에 servlet이 바뀌면 service도 바꿔야 하지 않겠는가?

 

더 큰 문제는 test가 쉽지 않다는 것이다.

 

service 계층에 특별한 기능이 없다면 데이터 액세스 계층과 합쳐도 된다. 근데 프레젠테이션 계층과 서비스 계층을 합치는 것을 추천하지 않는다. 트랜잭션 경계를 정하기가 애매하더 일단 범위가 너무 크다. 

 

794p.

DB/SQL 중심의 로직 구현

SQL중심으로 개발을 하다 보면 메서드 하나 당 SQL을 대변하는 경우가 있다. 대부분 중복이 불가피하고 공통적인 부분을 떼는 것 또한 쉽지 않다.

이렇게 되면 service는 그저 한번 들르는 곳의 역할만 하게 된다. 모든 비즈니스 로직은 SQL로 대변되기 때문이다.

이게 바람직한가? 하나의 SQL이 수백 줄의 자바 코드를 대체하는 것이? 이는 누가 유지보수를 할 것인가? 또 복잡한 SQL은 제한된 자원인 DB에 큰 부담을 준다. 요즘 애플리케이션 서버가 더 싸지는 데 비용적으로 보면 뭐가 옳을까?

 

당연하게 유지보수와 확장성을 생각하면 위처럼 하면 안 된다. 객체지향적이지 못하기 때문이다.

객체 지향적으로 개발하기 위해  오브젝트 중심의 아키텍처가 인기가 있어졌다.

이들은 기존은 SQL 중심의 개발과 다르게 매번 다른 도메인을 받는 것이 아닌 같은 도메인을 받는다. 물론 연관관계가 있을 때는 불필요한 도메인도 조회를 할 수 있다. 이는 성능에 문제가 된다. 그래서 해결법은 Lazy Loading이 등장했다.

모두 한 번에 가지고 오는 것이 아닌 사용할 때 관계 부분을 가지고 오는 것이다. 직접 코드로 구현을 해도 되고 ORM을 이용해도 된다.

 

814p.

도메인 오브젝트에 기능을 많이 넣게 되면 service를 DI 하는 일이 벌어지지 않는다. 하지만 다른 계층으로 이동시킬 때 도메인의 메서드를 호출할 수 있다는 단점이 있다. 이를 막기 위해서 DTO가 생겼다. DTO를 이용하면 값 변경에는 자유로워지고 그저 값을 이동시킬 뿐이다.