Layered Architecture

레이어드 아키텍처

 

계층을 분리하는 구조이다. 한 곳에서 모든 작업이 한꺼번에 이루어진다면 코드의 복잡성 증가, 유지보수의 어려움과 유연성 부족, 중복 코드의 증가, 낮은 확장성등 문제가 발생하기 때문이다.

 

1. Presentation layer : View

표현과 이벤트 처리, 데이터 포맷 책임

사용자와 최종 접점에 위치하여 사용자로부터 데이터를 입력 받거나, 요청된 데이터를 출력해 보이는 계층

외부로부터의 어플리케이션에 대한 요구를 받아들이는 동시에 처리 결과를 사용자에게 보여주는 부분이며, 컨트롤러의 구성 요소와 상호작용한다.

 

2. Control layer : Controller

구성 요서간의 처리 흐름을 제어, 데이터 조작 의뢰, 데이터 변환 및 연산, Exceptino과 Error 처리

사용자로부터 요청을 받고 응답을 처리하는 계층이다. 하위 계층에서 발생하는 Exception 이나 Error에 대한 처리를 맡으며, 최종 프레젠테이션 계층에 표현해야할 도메인 모델을 엮는 기능을 수행한다. 사용자로부터 전달 받은 데이터의 유효성을 검증하고 처리하고, 전체 시스템의 설정상태를 유지한다. 요청에 해당하는 비즈니스 로직을 결정하는 역할을 수행한다.

 

3. Business layer : Service

Control layer와 Preistence layer를 연결하는 역할, Transaction 처리

애플리케이션의 비즈니스 로직 처리와 비즈니스와 관련된 도메인 모델의 적합성을 검증하고, 트랜잭션을 처리한다.

Control계층과 Persistence계층을 연결하는 역할로서 두 계층이 직접 통신하지 않게 하여 애플리케이션의 유연승을 증가시킨다.

 

4. Persistence layer : DAO

영구 데이터를 빼내어 객체화 시키며, 영구 저장소에 데이터를 저장, 수정, 삭제하는 계층이다. 데이터베이스나 파일에 접근하여 데이터를 CRUD하는 계층이다.

5. Domain Model Layer : VO, DTO

관계형 데이터베이스의 엔티티와 비슷한 개념을 가지는 것으로 데이터 객체를 말한다.

 

MVC패턴의 세분화

 

프레젠테이션 계층 - 표현과 이벤트 처리, 데이터 포맷 책임

제어 계층 - 구성 요소간의 처리흐름의 제어, 데이터 조작 의뢰, 데이터 변환 및 연산, Exception, Error처리

비즈니스 계층 -컨트롤러와 뷰를 연결하는 역할, 다른 계층과 통신하기 위한 인터페이스 제공, 트랜잭션 처리 등

모델계층 은 비즈니스 계층과 퍼시스턴스 계층을 합친 계층이다.(입력,조회,수정,삭제를 담당한다.)

퍼시스턴스 계층 - JDO, Hibernate,ibatis,EJB

도메인 모델 계층 - 엔티티

 

필요한 이유

여러 웹페이지들을 보면 화면 구성에서 비슷한 동작을 하는 수많은 컴포넌트들이 합쳐진것을 알 수 있따.

이러한 화면마다 기능을 만든다고 한다면 중복되는 부분이 많을 것이다. 개발시 이러한 중복되는 부분을 하나의 서비스로 만들어서 사용하여 소스코드의 간결함을 추구 할 수 있다.

 

Service

비즈니스 로직을 수행하는 메소드를 가지고 있는 객체를 서비스 객체라고 합니다.

보통 하나의 비즈니스 로직은 하나의 트랜잭션으로 동작합니다.

 

Transaction

 원자성

 독립성

 일관성

 지속성

 

모델(Model)

데이터를 가진 객체를 모델이라 지칭한다.  데이터는 내부에 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다.

 

모델은 다음 규칙을 가지고 있음을 이해해야 한다.

1) 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.

즉, 화면에 네모 박스 안에 글자가 표현 된다면, 네모 박스의 화면 위치 정보, 네모 박스의 크기 정보, 글자 내용, 글자의 위치, 글자의 포멧 정보 등을 가지고 있어야 한다.

 

2) 뷰(View)나 컨트롤러(Controller)에 대해서 어떤 정보도 알지 말이야 한다.

 데이터 변경이 일어 났을때, 모델에서 화면 UI(View)를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안된다는 말이다.

 

3) 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.

모델의 속성 중 텍스트 정보가 변경되면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을때 이를 수신할 수 있는 처리 방법을 구현해야 한다. 이는 모델이 변경되는 방법을 다른 구성 요소들에게 알려주게 되는 방법이다.

 

 

뷰 (View)

화면에 표시되는 글자, 체크박스, 윈도우와 같은 UI라는 시각적 요소를 지칭한다.

 

뷰에서도 다음 규칙을 이해하고, 사용해야 한다.

1) 모델이 가지고 있는 정보를 따로 저장해서는 안된다.

화면에 글자를 표시 하기 위해, 모델 정보를 전달 받게 될텐데, 그 정보를 유지 하기 위해서 임의로 뷰 내부에 저장하면 안된다는 말이다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고, 그 화면을 그릴때 필요한 정보들은 저장하지 않는 다는 것이다. 

 

2) 모델이나 컨트롤러과 같이 다른 구성 요소를 몰라야 된다.

모델과 같이 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안된다. 그냥 뷰는 데이터를 받으면, 화면에 표시해주는 역할만 가진다고 보면된다. 각자 이기적이라고 보면 된다. '난 화면에만 그리고 그때 쓴 데이터는 쓰레기 통에 버릴꺼야' 하는 이기적인 녀석 말이다. 

 

3) 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.

모델과 같이 변경이 일어났을때 이에 누군가에게 변경을 알려줘야하는 방법을 구현해야 한다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서, 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현한다.

 

뭐 이쯤 읽었으면 이에 대한 처리 방법을 왜 구현해야 하는지 짐작할 수도 있을것이다. 이는 모델이나 뷰에서 변경이 일어났을때, 이를 컨트럴로에게 알리고, 컨트롤러는 어떻게 처리할지 결정해 다시 다른 구성 요소에서 변경을 알려주는 중재자 같은 역할을 위해 변경 통지 관련 처리 방법을 구현하는 이유이다.

 

 

컨트롤러 (Controller)

모델과 뷰를 연결해 주는 역할을 한다. 주로 비즈니스 로직(문제를 해결하기 위한 과정)이 이 컨트롤러에서 구현되어 있는 것이다. 음식 재료와 음식을 예를 들면, 음식 재료가 있고 이를 조리법을 이용해 음식을 완성한다고 했을때, 음식 재료들은 데이터가 될터이고, 조리법은 컨트롤러, 그리고 완성된 음식은 뷰로 표현할 수도 있을것 같은데... 예를 들고 보니 조금은 부적절하다는 생각도 들지만, 필자의 지식 수준이 여기까지라고 생각하고 글을 읽어주길 바란다.

 

컨트롤러는 다음 규칙을 이해해야 합니다.

1) 모델이나 뷰에 대해서 알고 있어야 한다.

모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데, 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.

 

2) 모델이나 뷰의 변경을 모니터링 해야 한다.

모델이나 뷰의 변경을 통지 받으면, 이를 해석해서 각각의 구성 요소에게 통지를 해야 하는것입니다.

출처: https://bsnippet.tistory.com/13 [snippet]