[10분 테코톡] 해리&션의 MVC 패턴

1. MVC 패턴이란?

디자인 패턴
SW 개발방법을 공식화 한 것
애플리케이션을 3가지 역할로 구분한 개발방법론


모델1
- 구성 : JSP + JavaBean(Service)
뷰와 로직이 섞인다.
 장점: 구조가 단순하다
 단점 : 출력과 로직 코드가 섞여, JSP 코드가 복잡해진다.
         프론트와 백엔드가 혼재되어 분업이 용이하지 않다.
         유지보수가 어렵다.


모델2
- 구성 : JavaBean(Service) + JSP + 서블릿
 MVC 구조와 비슷해짐
 장점 : 뷰와 로직의 분리로 모델1에 비해 덜 복잡하고 분업이 용이하며 유지보수가 쉽다.
 단점 : 모델1에 비해 습득이 어렵고 작업량이 많다.


MVC 흐름
1. 사용자는 원하는 기능을 처리하기 위한 모든 요청을 컨트롤러에 보낸다.
2. 컨트롤러는 모델을 사용하고, 모델은 알맞은 비즈니스 로직을 수행한다.
3. 컨트롤러는 사용자에게 보여줄 뷰를 선택한다.
4. 선택된 뷰는 사용자에게 알맞는 결과 확인을 보여준다.
   -> 이 때 사용자에게 보여줄 데이터는 컨트롤러를 통해서 전달받는다.


Model
- 값과 기능을 가지고 있는 객체
- 비즈니스 로직을 수행하게 된다.


View
- 모델에 포함된 데이터의 시각화
- 비즈니스 로직이 없다. (실수하기 쉬움)


Controller 
- 모델 객체로의 데이터 흐름을 제어
- 뷰와 모델의 역할을 분리


MVC 패턴을 사용하는 이유
- 각 컴포넌트의 코드 결합도를 낮추기 위해
- 코드 재사용성을 높이기 위해
- 구현자들 간의 커뮤니케이션 효율성을 높이기 위해


많이 실수하는 부분들1
- Model에서 View의 접근 또는 역할 수행
- to string에 대한 수정..


많이 실수하는 부분들2
- View에서 일어나는 '과한' 값 검증과 예외 처리


많이 실수하는 부분들3
- View에서 일어나는 비즈니스 로직
- 뷰와 모델끼리의 연산을 하면 안됨!!


Controller에서 중복 발생 ! -> 별도의 객체로 분리, 별도의 메서드로 분리


Service란?
비즈니스 로직을 수행하는 메서드를 가지고 있는 객체
비즈니스 메서드를 별도의 Service 객체에서 구현하도록 하고 컨트롤러는 Service 객체를 사용하도록 한다.


Service는 Transaction을 가지고 있는데 그 특징으로는

✔ ACID
1. 원자성 ( Atomicity )
- 하나의 원자 트랜젝션은 모두 성공하거나 or 모두 실패한다.
2. 일관성 ( Consistency )
- 트랜젝션 작업처리 결과가 항상 일관성 있어야한다.
3. 독립성 ( Isolation )
- 어느 하나의 트랜젝션이라도 다른 트랜젝션의 연산에 끼어들 수 없다.
4. 지속성 ( Durability )
- 트랜젝션이 성공적으로 완료되었을 경우, 결과는 영구적으로 반영되야 한다. 


Repository ( DAO, Data Access Object)
- DAO 자체는 아니지만, 지금 우리가 배운 단계에선 DAO같은 역할이란 소리
- 데이터 엑서스 메서드를 별도의 Repository 객체에서 구현
- Service는 Repository 객체를 사용


Summary

 

자료 : https://www.youtube.com/watch?v=uoVNJkyXX0I