[WIL] 항해99 (9기) - 4주차 회고

• 기간: 10/7 ~ 10/13
• 주제 : ORM, SQL, MVC

 

📌 MVC패턴

디자인 패턴 중 하나이다.

디자인 패턴이란,프로그램이나 어떤 특정한 것을 개발하는 중에 발생햇던 문제점들을 정리해서 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정한 "규약"을 통해 쉽게 쓸 수 있는 형태로 만든것을 말한다.예를 들어 어떠한 Data를 만들고 이 Data를 수정할 로직을 짠다. 그리고 그 Data를 보여주는 부분을 만들 때 하나하나가 로직이 분리가 안되어있고 한꺼번에 정의가 되어있다면 나중에 유지보수하기가 힘들다. 그걸 돋기위해 디자인패턴이라는게 나오는 것이며, 좀 더 쉽고 편리하게 사용할 수 있게 만든 특정한 방법들을 디자인 패턴이라고 한다.디자인 패턴이라는 것은 스트래티지 패턴, 옵저버 패턴 등등 정말 여러가지가 있고 그 중 하나가 바로 MVC 패턴이다.

 

MVC 는 Model, View, Controller의 약자 이다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴이다.

 

출처: XESCHOOL

위의 그림처럼 사용자가 controller를 조작하면 controller는 model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 된다.

 

🔑 모델 (Model)

데이터를 가진 객체를 모델이라고 지칭한다. 데이터는 내부의 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다. 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다. 이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있다.

 

모델의 규칙

• 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 함
• 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 함
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함

 

🔑 뷰 (View)

View는 클라이언트 측 기술은 HTML/CSS/Javascript들을 모와둔 컨테이너이다. 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어온다.

 

뷰의 규칙

• 모델이 가지고 있는 정보를 따로 저장해서는 안됨
• 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 함
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함

 

🔑 컨트롤러 (Controller)

사용자가 접근한 URL에 따라 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model을 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다.

모델에 명령을 보냄으로써 뷰의 상태를 변경할 수 있음 => (워드에서 문서 편집)
컨트롤러가 관련된 모델에 명령을 보냄으로써 뷰의 표시 방법을 바꿀 수 있음 => (문서를 스크롤하는 것)

 

컨트롤러의 규칙

• 모델이냐 뷰에 대해서 알고 있어야 함
• 모델이나 뷰의 변경을 모니터링해야 함

 

🔑 MVC 패턴을 사용해야 하는 이유

• 비즈니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행가능
• Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리함
• 중복 코딩의 문제점 제거

---

📌 ORM과 SQL 차이점

ORM (Object-Relation Mapping)

객체와 관계형 데이터베이스의 데이터를 자동으로 매핑시켜주는 프레임워크이다.

설정된 객체 간의 관계를 바탕으로 자동으로 SQL를 생성하여 실행한다.

SQL를 직접 작성할 필요가 없다.

 

장점

• ORM을 사용하면 SQL문이 아닌 클래스의 메서드를 통해 데이터베이스를 조작할 수 있어서 개발자가 객체 모델만 사용해서 프로그래밍을 하는 데 집중할 수 있게 한다.
• JPA의 경우 추상화된 데이터 접근 계층을 제공하기 때문에 특정 벤더에 종속적이지 않다. 즉 설정파일에서 어떤 DB를 사용하고 있는지 알려주기만 하면 얼마든지 DB를 변경할 수 있다.
• 스키마가 변경되었을 경우 Mybatis에서는 관련 DAO의 파라미터, 결과, SQL 등을 모두 확인하여 수정해야 하지만 JPA를 사용하면 이런 일들을 대신해준다.

단점

• 직접 SQL을 작정하는 것보다 성능이 떨어진다. (물론 해결법 또한 존재한다.)
• 메서드 호출로 DB데이터를 조작하기 때문에 세밀함이 떨어진다. 복잡한 통계 분석 쿼리를 메서드만으로 해결하는 것을 힘든 일이다.
• 러닝커브가 있다.

N+1 Problem

ORM 에서 성능 이슈가 발생하면 가장 흔한 원인으로 N+1 Problem이 언급된다.

N+1 Problem은 쿼리 1번으로 N건의 데이터를 가져왓는데 원하는 데이터를 얻기 위해 이 N 건의 데이터를 데이터 수 만큼 반복해서 2차적으로 쿼리를 수행하는 문제이다.

예를들어 2개의 팀이있고 2명의 멤버가 각각 다른팀에 들어가 있다고 생각해보자.

이때 모든 멤버를 조회하게 된다면,

모든 멤버 조회 -> 멤버들의 팀이 비어있으니까 채워서 반환시키기 위해 팀을 각각 쿼리를 날려서 가져옴

위와 같은 순서로 쿼리가 날아간다. 멤버가 수천, 수만명이라고 생각하면 굉장히 비효율 적이다.

N+1의 의미는 쿼리를 1개 날렸는데 그것 때문에 추가쿼리가 N개 나간다는 의미이다.

SQL Mapper

객체와 관계형 데이터베이스의 데이터를 개발자가 작성한 SQL로 매핑시켜주는 프레임워크이다.

개발자가 SQL을 직접 작성해야 하며 SQL문을 실행하고 얻은 데이터를 객체로 매핑시켜준다.

 

장점

• JDBC를 사용했을때 발생하는 불필요한 코드들을 줄일 수 있다.
• SQL이 코드와 분리되어 있기 때문에 유지보수가 편한다.
• SQL 쿼리를 그대로 사용하기에 복잡한 JOIN, 튜닝 등을 좀 더 수월하게 작성 가능하다.
• 동적 쿼리 생성에 유용하다.

단점

• 데이터베이스 설정 변경 시 수정할 부분이 너무 많다.
• 특정 DB에 종속적이다.

---

< 느낀점 >

이번 주차에는 Spring Security와 JWT의 사용방법을 배웠다. Spring을 주특기로 결정한 이래로 길고 복잡한 코드를 작성해 보는 것이 익숙하지 않았다. java 파일이 많이 생기면서 각 기능별로 분리해놓으니 확실히 찾아보기 싶고, 다른 사람이 작성해 놓은 코드를 분석할 때도 차례차례 따라가면서 볼 수 있어서 그 부분은 MVC의 최대 장점이라고 생각한다. 

 

DB를 조작하는 부분은 항상 Mapper파일을 만들어서 관리하곤했는데, ORM을 사용하니 직접 쿼리를 작성하지 않아도 데이터를 조작할 수 있어서 편리했다. 연관관꼐를 설정할 때 N+1문제를 고려하지 않으면 오버스택플로우가 빈번하게 발생했다.. 각 엔티티의 연관관계를 잘 생각해보고 사용해야 한다고 느꼈다