스프링에서 계층을 나눈 정확한 원인이 궁금합니다.

Question

스프링에서는 Controller , Service, Mapping 이런 식으로 계층을 나누고Controller의 경우 리퀘스트,Service의 경우 비즈니스 로직,Mapping의 경우 DB에 대한 접근을 담당하는 것으로 알고 있는데요. 계층을 나누는 이유는 제가 알기로는 예를 들어 Model2 MVC 의 경우 Controller에서 리퀘스트 &#43; 비즈니스 로직 처리까지 하면서 코드의 중복이 일어날 수 있기 때문에 Spring처럼 계층을 나눠서 코드를 작성해야 로직에 대한 중복제거와 더불어 유지보수와 확정성이 향상된다. 라고 알고 있습니다. 근데 Model2 MVC의 경우 어차피 Controller를 기능단위로 분할해서 만들텐데 어떻게 로직이 중복된다는 건가요,,,? 기능이 다른데 로직이 중복될 수도 있나요 ?

imkh · Answer

Controller에 service 영역 로직을 구현하는건 상관은 없지만.. 긴코드를 방지하고 나누는게 목적입니다.결론은 역할 분리가 이유라고 할수 있습니다.

DongGeon2 · Answer

imkh 답변감사합니다. 긴코드를 방지하기 위함이라는 것은긴코드가 결합도 증가, 유지보수와 확장성 하락으로 이어진다고 이해해도 되는건가요?그리고 비즈니스 로직의 중복은 일어나지 않는건가요??

chytonpide · Answer

네 n-tier아키텍쳐를 사용하면 각 관점에 따라서, 코드들을 분리하기 때문에 응집도가 높아집니다. 응집도가 높아진다는 것은 역할에 맞게 코드(클래스)가 분리되어 있다는게 되고, 이는 중복이 감소하고 코드 재사용성이 증가한다고도 말 할 수 있습니다. 당연히 응집도가 높으면 이후 유지보수에 도움이 되고 확장에도 도움이 됩니다. n-tier아키텍쳐를 사용하면서 각 레이어에 추상화를 적용하면 결합도가 감소합니다. 보통 스프링 프로젝트에서 mapper또는 dao, repository는 추상화된 interface를 사용합니다. 이렇게 persistence layer를 추상화해서 사용하면 이후에 영속성에 사용하는 기술이 달라져도 service layer의 코드가 영향을 받지 않습니다. 현재 mybatis 기술을 사용하고 있는 상태애서, spring jdbc나 spring jpa로 영속성 메카니즘을 바꿔도 service레이어는 오직 interface에만 의존적이기 때문에 이는 service layer의 알바가 아닙니다. 어플리케이션의 핵심이 되는 service레이어를 분리해서 가지고 있으면 이후에 프레젠테이션 레이어 에서 사용하는 기술의 변경이 쉽겠지요? 예를들어서 jsp 기술을 사용해서 직접 view를 만들어서 유저에게 전달하는 방식에서 REST API로 컨트롤러의 메카니즘을 변경한다고 칩시다. 비지니스로직이 서비스 레이어에 응집되어 있으면, 단순하게 메카니즘을 교체하는 작업이되지만 비니지스 로직이 컨트롤러 레이어에도 존재한다면 변경이 더 어렵겠지요?

DongGeon2 · Answer

yadameda 감사합니다!! 덕분에 정리가 됐습니다ㅎㅎ

스프링에서 계층을 나눈 정확한 원인이 궁금합니다.

4개의 답변

#layer 목록