MVC 패턴에 관한 고찰

프리코스를 진행하며 contoller와 service 계층을 습관적으로 두어서 구현했다. 하지만 지금 시점에서 과연 그런 계층이 왜 존재하는지, 장점은 무엇인지 궁금해졌다.

 

 

 

 

 

 

전에도 포스팅했었던 Spring 웹 계층인데, contoller에서 입출력과 관련된 부분을 맡고 service 계층에서 비즈니스 로직을 담당한다.

 

 

 

 

 

 

과제를 진행하면서 이 부분을 신경 썼다. contoller에서는 최대한 입출력과 관련된 부분을 담당하고 로직은 모두 service로 넘겨 구현했다.

하지만 이러다보니 service 객체가 너무 비대해지고, 프로그램의 모든 부분과 연관되어 있어 거의 모든 객체를 참조해야 한다.

 

 

 

 

 

 

이런 경우 문제점은 service 객체 존재에 명확한 이유가 없다. bridgeGameManager에 있는 메서드들을 굳이 service가 하고 있다고 느껴진다.

그럼 service 객체가 왜 필요한지 알아보자.

API의 추가 및 변경될 경우

다리 건너기 게임을 웹서비스로 확장해 Restful API로 제공한다고 가정하자. 웹페이지 요청을 받는 로직을 추가한다고 할 때, BridgeController에 추가해야 하지만 service 객체가 있을 경우 따로 객체를 만들어 구현하면 된다.

트랜잭션 처리

보통 service단에서 DB와 연결된 트랜잭션을 걸어두는데, @Transaction을 통해 Exception이 발생할 경우 안전하게 롤백하는 과정을 거칠 수 있다.

먼저 과제에서는 DB와 연결되지 않으므로 트랜잭션은 고려대상이 아니라고 할 수 있다. 하지만 API가 추가되거나 다리 생성, 이동, 결과 출력을 따로 contoller를 생성해 처리할 수도 있다.

그럼 service를 생성하지 않고 BridgeGame에서 핵심 로직을 구현하는 방식을 살펴보자.

 

 

 

 

 

 

contoller에서 입력을 받아 다리를 만든 후 BridgeGame을 생성한다.

 

 

 

 

 

 

BridgeGame에서는 다리를 생성자로 받고 필요한 객체를 생성하여 기능을 구현한다.

이 경우 BridgeGame 클래스는 다리 건너기 게임을 관리하는 클래스 라는 역할이 조금 더 명확해진다. service에서 구현할 경우 BridgeGameManager, UserBridge 등을 파라미터로 받아 메서드를 실행하는 중간단계 역할에 그치지만 BridgeGame에서 객체를 참조해 실행할 경우 이동, 재시작 등의 기능이 더 뚜렷해지는 것을 볼 수 있다.

 

 

service 객체의 유무에 따른 장단점을 살펴보았는데, 위의 경우에는 BridgeGame에 필요한 기능을 구현하는 것이 더 타당해 보이지만 상황에 따라 적절히 사용하는 것이 옳은 듯하다.