[asp.net] MVC 이해 - MVC 패턴

MVC 디자인 패턴과 그 안에 담겨있는 사상에 익숙해지기

 

- MVC 아키텍처 패턴

- 도메인 모델 및 리파지토리

- DI(Dependency Injection)를 이용한 느슨하게 결합된 시스템 만들기

- 자동화된 테스트 기초

 

MVC 응용프로그램의 상호작용은 사용자의 조작과 뷰의 갱신이 자연스럽게 맞물려 반복됨으로써 이루어지며, 이때 뷰에는 상태가 존재하지 않는 것으로 간주된다. 이는 Http의 요청과 응답과 잘 어울림.

또한 MVC는 도메인 모델 및 컨트롤러 로직을 사용자 인터페이스와 분리시킴으로써 자연스럽게 관심사의 분리(Seporation of Concerns)를 이끌어냄.

 

MVC 패턴 이해하기

모델 :

사용자가 작업할 데이터를 담거나 표현함.

모델에는 2가지 종류가 있음.

1. 뷰와 컨트롤러 간에 전달되는 데이터만을 담고 있는 단순한 뷰 모델(View Model)

2. 업무 도메인의 데이터 뿐만 아니라 데이터에 대한 작업과 변환, 그리고 조작 규칙을 담고 있는 도메인 모델(Domain Model)일 수 있음.

 

뷰:

뷰는 모델의 특정 부분을 사용자 인터페이스로 렌더하는 데 사용된다.

 

컨트롤러:

컨트롤러는 전달받은 요청을 처리하고 모델을 이용해서 작업을 수행하며, 사용자에게 렌더될 뷰를 선택한다.

 

도메인 모델

 

설명

소프트웨어 공학에서 도메인 모델은 행위와 데이터를 둘 다 아우르는 도메인의 개념 모델이다.

 

https://incheol-jung.gitbook.io/docs/study/ddd-start/1

1장 도메인 모델 시작 - Incheol's TECH BLOG

 

모델은 응용프로그램이 작업을 수행하는 세계에 대한 정의이다.

ex) '은행 업무 응용프로그램의 모델'은 계정이나 일반 원장, 고객의 신용 한도를 비롯해서 입금 및 계좌 인출 등과 같은 모델의 데이터를 조작하는 작업을 포함한, 응용프로그램이 지원하는 은행의 모든 것을 표현한다.

또한 모든 거래를 원장에 추가해야 한다거나 고객이 지정한 한도나 은행이 보유하고 있는 금액보다 더 많은 금액을 인출하지 못하게 하는 등 데이터의 전반적인 상태와 일관성 유지에 대한 책임도 있다.

 

반대로 모델과 관련없는 부분을 검토함으로써 모델을 정의할 수도 있음.

: 모델은 UI 렌더링이나 요청 처리는 다루지 않음. -> 이것은 뷰와 컨트롤러의 담당.

뷰는 모델의 요소들을 사용자에게 출력하기 위한 로직을 담고 있으며, 사실상 그것이 뷰가 처리할 전부.

뷰는 모델을 직접적으로 인식하지 않으며 직접 모델과 소통하지 않음.

컨트롤러는 뷰와 모델을 연결해주는 다리임.

클라이언트로부터 전달된 요청은 컨트롤러에 의해서 처리되며, 컨트롤러가 사용자에게 보여줄 적절한 뷰를 선정하고, 필요한 경우, 모델을 이용해서 적절한 작업을 수행한다.

 

모델의 데이터 조작은 오직 모델에만 존재함.

데이터 출력은 오직 뷰에서만 진행.

사용자의 요청과 입력을 처리하는 코드는 오직 컨트롤러에만 존재함.

 

도메인 모델 이해하기

MVC 응용프로그램에서 가장 중요한 부분은 도메인 모델이다.

모델은 응용프로그램이 반드시 지원해야만 하는 현실 세계의 특정 산업이나 업무에 필요한 엔티티, 작업, 규칙들을 규정함으로써 정의하게 되는데, 이를 도메인이라고 한다.

 

그런 다음 이 도메인을 소프트웨어적으로 표현한 도메인 모델을 생성하게 된다.

asp.net mvc 프레임워크에서 도메인 모델은 도메인 형식(Domain Type)으로 알려진 C# 형식(클래스, 구조체)들의 모음이다. 도메인 작업은 도메인 형식에 정의되는 메서드로 표현되며, 도메인 규칙은 이 메서드의 내부 로직이나 c# 어트리뷰트로 표현된다.(ex [HttpPost])

그리고 데이터의 일부분을 표현하기 위해서 도메인 형식의 인스턴스를 생성하게 되는데, 이 인스턴스가 바로 도메인 개체(Domain Object)이다.

도메인 모델은 대부분 저장소에 저장되어 장기간 유지되는 것이 일반적, 영속화를 위해 다양한 방법이 있으나 역시 DBMS가 가장 많이 사용됨.

 

간단 정리

: 도메인 모델은 앱 내의 업무 및 데이터 및 절차에 대한 신뢰할 수 있는 단일 정의이다. 영속화된 도메인 모델 역시 도메인의 표현 상태에 대한 신뢰할 수 있는 정의이다.

 

도메인 모델 접근 방식은 응용프로그램을 유지보수 할 때 발생하는 많은 문제점들을 해결해준다.

모델의 데이터를 처리해야 한다거나 새로운 절차나 규칙을 추가해야 할 경우, 응용프로그램에서 오직 도메인 모델 한 곳만 변경하면 되기 때문이다.

Tip

도메인 모델과 앱 의 다른 부분을 강제로 분리하는 가장 일반적인 방법은 모델을 별도의 C# 어셈블리에 작성하는 것.

이 방법을 사용할 때 응용프로그램의 다른 부분들을은 도메인 모델에 참조할 수 있어야 하나, 반대로 모데인 모델은 다른 부분들을 참조해서는 안 됨. 큰 프로젝트에서 유용하다고 함.

 

MVC 구현

일반적으로 asp.net의 controller는 System.Web.Mvc.Controller 클래스에서 파생된 C# 클래스다.

그리고 이렇게 파생된 클래스에 정의된 각각의 public 메서드들은 액션 메서드라고 부르며 이 엑션 메서드들은 asp.net 라우팅 시스템을 통해서 구성할 수 있는 URL과 연결된다.

특정 액션 메서드와 연결되어 있는 url로 요청이 전달되면 컨트롤러 클래스의 구문이 실행되어 도메인 모델을 대상으로 필요한 작업을 수행한 다음, 클라이언트에 출력될 뷰를 선택한다.

 

asp.net 프레임워크는 뷰를 처리하고 브라우저에 대한 응답을 생성하기 위해서 뷰 엔진이라는 구성요소를 사용한다.

뷰엔진 = Razor 뷰 엔진.

그러나 .net은 도메인 모델 구현 방식에 있어서는 어떤 제약도 강요하지 않음.

평범한 C# 개채를 이용한 모델 생성이나 특정 종류의 DB 혹은 개체-관계 매핑(Object-Relational Mapping) 프레임 워크 또는 .net에 의해 지원되는 그 밖의 모든 데이터 도구들을 사용해서 영속과를 구현할 수 있다.

 

MVC왜 패턴

 - 스마트 UI

: 마치 asp.net forms 같음.

개발자들이 디자인 화면에 구성요소나 컨트롤를 드래그해서 인터페이스부터 구성한다.

이 컨트롤들은 이벤트를 발생시켜 사용자와의 상호작용을 통보해준다. 개발자는 이 이벤트들에 대응하는 코드를 일련의 이벤트 처리기에 작성하게 되는데, 이벤트 처리기는 특정 컨트롤레엇 특정 이벤트가 발생할 때 호출되는 작은 코드 블록을 말한다.

장점 : 신속하게 결과를 업음

단점 : 유지보수가 어려움. 특별한 사항이 아니면 고려하지 않는 패턴

하나에 모든 것이 몰려있는 스타일

 

                           (영속화)

요청 ->   스마트  -> 데이터

응답 <-      UI     <- 베이스

 

- 모델-뷰 아키텍처

스마트 UI 패턴에서 유지보수 문제가 발생하게 되는 주된 부분은 업무 로직 쪽인데 이는 로직이 응용프로그램 전체에 걸쳐 넓게 분산돼서 기능을 변경하거나 추가하는 작업이 만만치 않기 때문이다. 이를 개선하기 위해 나온 패턴.

업무로직을 빼내어 별도의 도메인 모델로 분리시킴.

 

                                           (영속화)

요청 ->      뷰     ->     모      ->관계형

응답 <-      UI     <-     델     <- 데이터 베이스

 

단점

1. 스마트 UI보다 유지보수가 쉽지만, 여전히 UI와 도메인 모델이 긴밀함.

2. 일반적으로 모델에는 데이터 접근을 위한 대량의 코드가 포함되게 되는데, 결과적으로 이는 데이터 모델에 업무 데이터와 작업, 그리고 규칙들 이외의 것이 포함될 가능성이 매우 높아진다.

 

- 3-티어 아키텍처

모델-뷰 아키텍처를 개선하기 위해, 3-티어 혹은 3-레이어 패턴에서는 영속화 코드를 "도메인 모델"로부터 분리해서 데이터 접근 레이어(DAL, Data Access Layer)라는 이름의 새로운 구성요소로 이동시켰다. 

 

                                              (영속화)

요청 ->      뷰     ->     모     ->    데이터    -> 관계형

응답 <-      UI     <-     델     <- 접근레이어 <- 데이터 베이스

3티어 아키텍처는 업무용 프로그램에서 가장  폭 넓게 사용되는 패턴이다.

3-티어 응용프로그램과 MVC 패턴은 유사성을 띈다.

MVC와 다른 점은 UI 레이어가 클릭 및 이벤트 기반의 GUI 프레임워크가 직접적으로 연결되어 있기 때문에(Windows Forms 처럼), 자동화된 단위 테스트의 수행이 사실상 겅의 불가능하다는 것이다.

3-티어 앱의 UI는 매우 복잡해질 수 있기 때문에, 그 경우에는 철저하기 테스트 할 수 없는 UI 관련 코드가 대량으로 만들어질 수 있음.

3-티어 패턴에는 UI 티어에 대한 강제적인 규칙이 부족하기 때문에 최악의 경우 스마트 UI와 다를 것이 없어짐.

 

MVC를 기반으로 변형된 패턴

모델-뷰-프리젠터(Model-View-Presenter)는 상태가 존재하는 GUI 플랫폼에 보다 손 쉽게 적용할 수 있도록 설계된 MVC 변형 패턴이다.

이 패턴에서 프리젠터는  MVC의 컨트롤러와 같은 역할을 수행할 뿐만 아니라 상태가 존재하는 뷰와 보다 밀접한 관계를 맺고 사용자의 입력과 동작에 따라 UI 구성요소에 출력되는 값들을 직접 관리한다.

이 패턴에는 다음과 같이 두가지 구현 방식이 존재 

- 뷰에 로직이 전혀 존재하지 안는 수동적 뷰(Passive View) 구현, 뷰는 단지 프리젠터에 의헤 직접 관리되는 UI 컨트롤러에 불과하다.

- 감독 컨트롤러(Supervising Controller) 구현, 뷰가 데이터 바인딩 같은 프리젠터 로직의 일부 요소를 담당하거나, 도메인 모델로부터 전달된 데이터 원본에 대한 참조를 갖고 있는 경우도 있다.

이 두 가지 접근 방식의 차이점은 뷰가 얼마나 지능적인지에 따라 구분 됨. 다만 두 가지 방식 모두 프리젠터가 GUI 프레임워크와 분리 되어있기에 로직이 상당히 단순하고, 단위 테스트에도 적합하다.

 

모델-뷰-뷰 모델(MVVM) 패턴

Microsoft로 부터 비롯되었으며 WFP(Window presentation Foundametal)에서 사용 중..

모델과 뷰는 MVC의 MV와 동일,

뷰모델이란?

사용자 인터페이스의 추상적 표현으로 보통 뷰 모델은 UI에 출력될 데이터들에 대한 속성들과 UI에 의해서 호출될 수 있는 데이터에 대한 작업들을 노출하는 C# 클래스다.

컨트롤러와는 달리 MVVM의 뷰 모델에는 뷰의 존재에 대한 개념이 존재하지 않는다.

MVVM 의 뷰는 WPF의 바인딩 기능을 이용해서 (뷰의 컨트롤들에 의해 노출된 속성)들과 (뷰 모델에 의해 노출된 속성)들을 양방향으로 연결해준다.

MVC 내에서도 뷰모델이란 말을 사용하나, 데이터와 작어브 그리고 규칙들의 세련된 표현인 도메인과는 달리, 컨트롤러에서 뷰로 데이터를 전달하기 위한 목적으로만 사용되는 단순한 모델 클래스를 의미한다.