리제네아
2016-12-28 10:20:41 작성 2016-12-28 10:21:20 수정됨
7
10615

[Spring] Controller 가 아닌 Service 에서 비즈니스 로직을 작성하는 이유?


지금까지 Controller 에서 비즈니스 로직을 작성했는데


어느 순간부터 Service 에서 비즈니스 로직을 작성해야 된다는 소리를 들었습니다.


Controller에서 request 객체라던지 model 객체 등

많은 객체를 사용, 가공 할 수 있는데 왜 Service에서 하라는 걸까요?


아직, Service에서 비즈니스 로직을 구현해보지 않았는데.


만약, Serivce에서 비즈니스 로직을 구현한다면,

Controller에서 Service를 호출 할 때 request 객체라던지 model 객체 등을 파라미터로 넘겨준다음

Service에서 사용해야 하는 건가요?

1
  • 답변 7

  • iops
    1k
    2016-12-28 10:39:09

    모든 프로그래밍에서 하나의 로직을 별도의 파일로 분리하는 이유는 아주 간단합니다.

    재사용 때문이죠.

    비즈니스 로직을 재사용 하기 위해 Service Layer에서 처리하라는 겁니다.

  • withdrawal
    2016-12-28 10:45:44

    사실 컨트롤러에서 전부 다 해도 프로그램은 동작합니다. 재사용과 유지보수를 위해 분리하는 습관을 가지면 좋습니다. 저는 service에서 데이터를 가공하고 dao에서 가공된 데이터로 결과값을 받아오는게 깔끔한거 같습니다. 각자 취향이죠

  • asd
    16k
    2016-12-28 10:46:32

    컨트롤러에서 서비스로 파라미터를 넘길때 request객체나 model을 그대로 던지는게 아니라 알맞는 POJO형태의 객체로 파라미터를 가공한 후 던지면 됩니다.

    그럼 서비스는 그걸 받아서 비즈니스 로직을 처리하고 결과를 리턴하면 컨트롤러가 다시 그걸 받아서 모델에 담고 뷰로 전달하겠죠.

    로직을 서비스에 담는 이유는, 비슷한 처리를 서로 다른 페이지에서 요청한다면 각각의 컨트롤러에 중복코드가 발생하지않을까요? 그걸 해결하기 위함입니다.

    그리고 서비스에 request같은 파라미터를 넘기지 않는 이유는 서비스는 화면에 독립적이어야하기때문입니다. 지금이야 웹 서비스니 request 객체가 넘어오지만 만약 뷰가 웹 서비스가 아니라면? 뷰가 바뀌면 컨트롤러만 바뀌면 되는데 서비스가 request같은곳에 의존성을 갖게되면 뷰가 바꼈을때 서비스도 수정되어야 하겠죠.

  • Mambo
    5k
    2016-12-28 10:50:33

    저도 공부하고 입장이지만...

    컨트롤러에서는 서비스 객체들을 주입받아 사용하는 것일거에요 비즈니스 로직이란게 데이터와 관련해서 저장하고 수정하고 없애는 일련의 동작을 여러 컨트롤러에서 사용할 가능성이 있으니까 컨트롤러 내에서 처리하지 않고 서비스 객체들에게 위임해서 처리하고 컨트롤러는 처리된 결과를 받아 응답하는 거죠

    만약 비즈니스 로직에 문제가 발생하였을때, 모든 컨트롤러의 로직을 변경하는 것보다는 문제되는 로직을 갖는 서비스 객체를 수정하는 것이 좋은 것 처럼 이렇게 분리하는 이유는 추후 유지보수에 용이하도록 하려는 방법인 것 같아요

  • fender
    18k
    2016-12-28 11:15:52

    기본적으로 '비즈니스'라는 것을 어떻게 바라볼 것인가에 대한 접근 방법의 문제입니다.

    어떤 개발자들은 비즈니스를 ERD라고 생각할 수도 있고, 다른 개발자들은 웹 페이지의 묶음이라고 생각할 수도 있을 것입니다.

    하지만 객체지향 언어를 사용한다면 적어도 정석이라고 할 수 있는 답은 '추상화, 계층화된 API의 모음'이라는 것이고, 그런 관점에서 볼 때는 비즈니스 계층에 '요청'이나 '응답' 같은 웹페이지 처리에 특화된 개념을 API에 노출시키는 것은 매우 잘못된 설계입니다. 쇼핑몰 사이트의 '비즈니스'는 상품 거래이지 서블릿 구동이 아니니까요.

    따져보면, '컨트롤러 계층에 비즈니스 로직을 구현한다'는 이야기 자체가 '비즈니스'를 결국 데이터베이스 연동이나 페이지 처리와 동일한 것으로 전제를 하는 것입니다. 컨트롤러에서 마이바티스로 테이블을 조작할 수야 있겠지만 '상품 구매' 같은 API를 재활용 가능한 형태로 표현하기는 쉽지 않습니다.

    실무에서 비즈니스 API를 제대로 설계하는 경우가 극히 드물고 사실상 서비스에서도 DAO의 역할을 중복적으로 정의하는 식이 관행이 되다보니 이럴 거면 왜 서비스 계층이 필요한지 모르겠다는 의문이 드는 경우가 생기는 것 같습니다.

  • 이박사
    393
    2016-12-28 11:21:27

    위에서 다들 답변 잘해주셨는데 추가로 공통적인 키워드는 "재사용" 이겠죠. 

    그리고 서비스에서 비즈니스로직을 작성하면 뷰에 종속되지않으므로 스펙의 변경 예를 들면 웹 -> 모바일앱으로 변경된다면 해당 비즈니스로직을 그대로 가지고 갈 수 있습니다. 

    단위 테스트시에도 서비스레이어에 비즈니스로직을 작성하면 테스트도 유용합니다. 


  • 리제네아
    2016-12-28 13:23:55

    모든 분들을 답변으로 채택하고 싶지만 그러질 못하네요.

    답변 감사합니다.

    많은 도움이 되었습니다. :D

  • 로그인을 하시면 답변 을 등록할 수 있습니다.