mvc구조
mvc구조는 model,view,controller로 구성된 구조이다.
model,view,controller은 간략히 말하자면
model(실제 데이터의 저장,변경이 이뤄지는 실제 동작이 수행되는 부분)
view(화면에 그려지는 부분)
controller(모델과 뷰를 제어하는 부분) 이다.
즉 MVC패턴이란 화면을 담당하는 부분(view), 데이터의 처리와 저장을 담당하는 부분(model), 이 두 부분을 매핑하고 제어하는 부분(controller)를 나누어 개발하는 방법을 말한다.
mvc의 배경,장점
MVC 아키텍쳐의 장점과 한계가 있다.
과거 MVC가 일반적이지 않던 시절에는 프리젠테이션과 비지니스 모델이 서로 뒤엉켜 있었기 때문에 하나의 기능을 수행하기 위해서는 불가피하게 로우레벨의 기술(Data Access, Transaction)들이 프리젠테이션 영역까지 침범할 수 밖에 없었다. 이런 1Tier, 2Tier 아키텍쳐는 갈수록 프로그램의 구조를 복잡하게 했다. 중복되는 코드와 복잡한 연관관계를 갖는 클래스들 때문에 엄청난 버그들을 수정하는 과정을 겪어야했다. 모두들 새로운 아키텍쳐의 필요성을 절실하게 느끼고 있었으며 이런 기대에 부응하듯 2Tier를 새로 정의하는 3Tier,ㅡ즉 MVC 아키텍쳐가 탄생하게 되었다.
MVC 아키텍쳐를 이용하는 목적은 다음과 같다. 복잡한 로우레벨의 기술을 처리하는 비지니스 모델을 뷰(프리젠테이션) 와 분리해냄으로써 개발자와 디자이너 사이의 업무영역을 효율적으로 분할한다. 그리고 DB 정보가 누출, 코드의 중복을 제거함으로써 보안효과를 높이며 코드의 오류를 최소화한다. 이러한 장점을 가지고 있는 MVC 아키텍쳐는 큰 호응을 얻게 되어 지금까지도 널리 쓰인다.
MVC 아키텍쳐의 개발방식을 돕는 JdbcTemplate나 Hibernate, MyBatis같은 간편한 퍼시스턴스 계층 프레임워크들이 탄생함과 동시에 스프링, 스트럿츠와 같이 MVC 개발을 돕는 고급 프레임워크들도 생겨나 쓰이고 있다.
mvc의 한계
MVC 패턴이 획기적인 디자인 모델이라는 사실은 분명하다. 하지만 너무 과도한 역할 분담 때문인지 과거 1Tier, 2Tier 계층이 갖고 있었던 직관적인 설계의 장점은 송두리 지워버렸다는게 문제였다.
사람은 본능적으로 객체지향적으로 생각하지 mvc구조에 맞게 생각하지는 않는다. 사람이 손가락,발가락을 움직인다고 생각하지 사람이 뇌에 의존해 뇌에서의 전기신호가 손가락과 연동해 동작시킨다고 까지는 생각하지 않는다.
모든 데이터의 처리가 데이터 자체가 아니라 데이터의 controller를 통해서 이뤄지는 것은 직관성이 떨어지며 프로젝트의 규모가 커질수록 controller가 비대해지고 복잡해지며 model과 view의 연결성도 강해진다.
계층화 구조
그렇다면 이 mvc구조와 같이 사용되기도 하는 service와 dao는 무엇인가.
이것은 계층화 구조(layered architecture)의 영향으로 생성되는 부분이다. mvc패턴만으로는 해결되지 복잡성을 계층화 구조를 통해 해결할 수 있다.
layered architecture는 Presentation Layer,Business Layer,Persistence Layer,Database Layer로 나뉘어져 있다.
-
-
Presentation layer
웹 페이지,ui를 화면에 보여주고 api로 통신하는 영역이다. -
Business layer
보안,접근권한,인증,허가 설정,validation, middle ware,proxy 등의 business의 수행을 위한 요소들이 포함되는 계층이다. -
Persistent layer(data Access layer)
data를 위한 presentation계층이라 볼 수 있다. dao,ORM을 포함한다. 어플리케이션 level에서 db로부터 가져와 ram에 저장된 데이터들을 관리하는 계층이다. -
Database layer
실제 데이터베이스 부분(mysql,oracle,mariddb.mongodb...)과 SANs
(Storage Area Networks)를 가리킨다.
presentation계층에서 화면에 보이고 페이지,데이터를 매핑하는 부분을 처리하고, business layer에서 서비스를 위한 보안설정,실제 로직을 처리하며 persistence layer에서 데이터들을 불러오고 관리하며 database layer의 db에서 데이터들을 db에 저장한다. 아래가 spring에서의 예이다.
Spring의 경우
Presentation Layer-> View와 Controller,
Business Layer-> Service
Persistence Layer->DAO
Database Layer->데이터베이스 부분
이렇게 계층 아키텍쳐를 구현하는 방법 중 하나로 mvc패턴의 model,view,controller가 사용된다.
- 스프링 웹 계층
dto의 필요성?
계층간의 연결에 흔히 dto가 쓰이지만 필요성에 의문을 제기할 수도 있다. 그냥 db에서 받은 형식 그대로 데이터를 다루며 타 계층에 넘겨주는 방법을 쓰면 굳이 dto를 따로 만들지 않아도 되기는 하다. dto가 사용되는 이유 몇가지가 있다.
- entity의 노출을 막는다.
db와 연결된 entity는 여러군데에서 접근이 가능하게 된다면 의도치 않은 수정이 발생하게 되고 이는 db데이터의 consistency에 문제를 초래한다.
성능 상으로도,보안상으로도 함부로 연결되어서는 안되는 db의 데이터가 아무데에서나 쓰여서는 안된다. - multiple calls를 방지
db에 접근할 때마다 성능에 쓰이는 자원이 사용된다. db로부터 한 번 가져온 이후에는 어플리케이션 레벨에 저장해 사용하면(dto로 다루면) 서버의 부하를 줄일 수 있다. - 여러 entity외의 정보도 혼합해 넘겨줄 수 있게 된다.
entity뿐만 다른 데이터까지 결합하여 넘길 필요가 있는 경우, dto로 정의해 넘기는 것이 유리하다.
dto의 위치
dto패키지의 위치는 정해진 것이 아니다. 때문에 프로젝트의 특성에 따라 위치를 고려해야 한다. dto가 여러 패키지에서 쓰이는 경우 dto라는 패키지가 따로 만들어져 관리되는 게 나을 수도 있고,
dto가 특정 계층까지만 쓰인다면 해당 계층에 dto를 둘 수도 있다.
도메인의 종류가 매우 다양한 큰 프로젝트의 경우 domain마다 dto가 함께 관리되는 것이 나을 수도 있다.
+참고: https://www.inflearn.com/questions/24222
dto의 사용범위
service레이어의 목적 중 하나는 도메인을 보호(캡슐화)하는 것이다.
controller에서 dto를 변환하려 하면 의존해야 하는 service가 필요이상으로 많아질 수 있다. 또한 controller에서 entity를 생성하기위해 repository에서 얻을 수 있는 정보까지 필요한 경우가 있다.
때문에 dto를 변환하는 위치는 service가 되는 것이 적절한 경우가 많다.
https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/
예시-writequiz플젝 구조
view(mvc의 view) -> react 프론트엔드이며 controller로 api통신하며 연결된다.
(mvc의 controller가 view와 model을 분리하고 연결하며 제어) -> controller의 api는 service를 이용해 비즈니스 로직(post저장,수정,삭제 등)을 수행한다.
- controller가 service에 의존
(mvc의 model)-> 비즈니스 로직은 service가 dao라고 할 수 있는 repository의 함수들을 이용해 db에 정보를 저장,수정,삭제하며 수행된다.
- service가 repository에 의존
Service는 계층화 구조의 일종으로 business layer이 구현된 것으로 controller와 model부의 부담을 덜으며 transation의 정의까지 할 수 있고,config와 같은 보안설정도 business layer의 일부이다.
respoitory과 db와 연결되는 dao가 되어 data access layer을 구현한다.
