MVC의 개념
MVC는 소프트웨어 설계와 관련된 디자인 패턴이다. 소프트웨어 공학에서 사용되는 설계 패턴
mvc의 간략한 이해
MVC란 model view Controller의 약자
MVC는 프레임워크나 라이버리를 지칭하는 것이 아니다.
소프트웨어가 서비스하는 방식에 대한 패턴을 지칭한다.
MVC 디자인 패턴 특징
소프트웨어가 서비스하기 위해서는 여러 과정이 필요하다.
그러한 처리를 각 기능 단위 별로 나눠서 처리한다.
프로그래밍을 할 때 정돈된 코드를 작성이 가능하다.
디버깅 가독성을 높인다.
Model은 데이터베이스와 연동을 해서 데이터를 저장하고 불러오는 작업을 수행한다.
View는 사용자 인터페이스, 사용자가 보는 화면과 버튼 폼을 디자인 하고 구현한다.
Controller 사용자에게 입력을 받아 Model에게 전달하고, View를 업데이트 한다.
mvc 패턴은 DispatcherServlet이 중앙에서 HTTP요청을 처리해준다.
Front Controller 패턴으로 설계가 되어있다. 이것으로 HTTP요청을 효율적으로 처리한다.
사용자가 Client를 통해서 서버에 HTTP 리퀘스트 api요청을 한다.
요청을 받은 Servlet 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성
설정 정보를 통해 어떤 servlet에 대한 요청인지 찾는다.
servlet에서는 service 메서드를 호출한 뒤 브라우저 요청 메소드에 따라 doGet 혹은 doPost등의 메서드를 호출
HttpServletResponse 객체의 응답을 담아 clinet에 반환
응답이 완료되면 생성한 HttpServletRequest, HttpServletResponse 객체를 소멸합니다.
DTO의 이해
DTO를 하기 앞서 DTO의 약자 Data Access Object
db의 데이터에 접근하기 위한 객체로 실제로 db에 접근하는 객체이다.
프로젝트 서비스 모델과 실제 db를 연결하는 역할을 한다.
jpa에서는 crud 작업을하는 Repository 객체들이 dao라고 한다.
DTO는 계층 간 데이터 교환을 하기 위해 사용되는 객체로 로직을 가지지 않는 순수한 데이터 객체이다.
DTO는 순수한 데이터 객체로서 속성과 속성에 접근하기 위한 게터 세터를 가진 클래스이다
DTO 사용의 장점
DTO 대신 도메인 모델을 계층간 전달에 사용하면, UI 계층에서 도메인 모델의 메소드를 호출하거나 상태를 변경시킬 수 있다. 또한 UI화면마다 사용하는 도메인 모델의 정보는 상이하다. 하지만 도메인 모델은 UI에 필요하지 않은 정보까지 가지고 있다. 이런 모든 도메인 모델 속성이 외부에 노출되면 보안 문제가 발생할 수 있다. 즉, 도메인 모델을 캡슐화 하여 보호할 수 있다.
장점 : DTO를 사용하면 이 결합을 느슨하게 만들 수 있다.
3 Layer 아키텍처의 이해
3 Layer 아키텍처를 사용하는 이유는 하나의 클래스에서 컨트롤러가 모든 api를 처리를 한다면 나중에 코드가 복잡해 진다면 한 클래스안에서 모든 것을 작성을 해야한다. 그래서 나온 개념이 3 layer 아키택처
- 클라이언트의 요청을 받습니다.
- 요청에 대한 로직 처리는 Service에게 전담합니다. Request 데이터가 있다면 Service에 같이 전달합니다.
- Service에서 처리 완료된 결과를 클라이언트에게 응답합니다.
IoC(Inversion of Control)
사용자의 요청이 들어오면 요청에 알맞게 bean을 생성을 해서 필요한 일을 하도록 시킨다.
해당 Bean이 할 일을 마치면 Bean을 삭제해준다.
컨테이너
프로그래머가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸(객체의 생애 주기)을 관리한다.
DI
DI는 IoC 프로그래밍 모델을 구현하는 방식 중 하나 이다.
빈은 간략하게 스프링 컨테이너가 생성해준 자바 객체
스프링 부트에서는 @가 붙은 어노테이션으로 객체를 빈으로 등록해 사용한다.
IOC DI에 대한 또 다른 이해
기계 부품에서 하나의 부품을 교체를 하고 바꾸고 싶다면, 자동차 전체가 아닌 엔진만 뽑아서 바꾸어주면 된다.
IOC DI는 의존성 주입등과 같은 개념을 이용을 해서 클래스에 대한 변경이 필요하면 다른 클래스에 영향을 끼치지 않으면서 변경이 가능해야 한다. 이런 수월한 기능들이 ioc di이다.
직접 클래스에 new 연산자를 이용하여 생성했다. 하지만 di는 직접적인 코딩이 아니라
컨테이너에게 이러한 일을 시키는 것이다. 이렇게 된다면 클래스의 변경이 자유로워지고
느슨한 결합을 만들어 준다.
스프링 자체에서 설정을 통해 연관 관계를 맺어줌을써 결합다로를 낮춰준다.
DI를 해야하는 이유
- 클래스들 간 의존 관계를 최소화 할 수 있다.
- 프로젝트 유지보수가 용이하다.
- 기존에는 개발자가 직접 객체의 생성과 소멸을 제어했는데 DI로 인해 객체의 생성과 소멸 등 클래스간 의존관계를 스프링 컨테이너가 제어해준다.
DI는 객체의 생성, 소멸, 의존 관계를 개발자가 직접 설정하는 것이 아니라 XML이나 애너테이션을 통해 스프링 프레임워크가 제어합니다.
스프링에서는 의존하는 객체를 컨테이너 실행 시 객체를 주입하기 때문에 DI라고 부릅니다. 여기서 각 클래스 객체를 Bean이라고 부르는데 이는 의존관계를 설정하는 xml 파일에서 각각의 객체를 <bean> 태그로 표시하기 때문입니다