달력

122021  이전 다음

  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  

Controller 와 Service의 차이점
레이어를 나누는 것은, 아, 티어(tier)라고도 합니다. ^^; 나누는 기준은 뭘까요. 그냥 나누는 사람도 많습니다. 레거시 코드들이 증인석에 출두할 수도 있으니까요.

2006년 스프링으로 프로젝트를 하면서 그 때는 이 고민을 하지 못했습니다. 납기일 내에 동작하는 프로그램을 만들어 내야 하니까요. 플젝이 끝나고 그것을 기반으로 확장하는 프로젝트가 많이 열렸습니다.
^^; 슬프게도 사람이 많이 바뀌었습니다. 히스토리를 알고 얘기해 줄 사람도 n모사 s모사로 가버린 다음이죠.

다행히 코드 리뷰라는 것을 새로운 플젝의 외주 사람들과 매일 규칙적으로 한시간 정도 안되게 하는데, 나온 질문입니다.

얘기가 긴 데요. It's a long story.

핵심은 request, response 같은 WAS 디펜던트 한 것을 서비스에서 처리하게 하면 안됩니다. 서비스는 WAS없이도 돌아간다라고 생각하고 짜야된다가 현재의 결론입니다.
^^;

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 토비  댓글주소 수정/삭제 댓글쓰기 2008.07.15 17:39

    Servier는 DB가 없이도 돌아갈 수 있어야 되기도 하죠.

  2. 알 수 없는 사용자  댓글주소 수정/삭제 댓글쓰기 2008.07.15 17:55

    그런 생각으로 서비스 레이어를 많이 만들기도 했는데 짜친 녀석 가지고 그러기도 뭐 해서 콘트롤러가 일 하게도 만들어봤어요. ㅋㅎ

  3. 해피씨커  댓글주소 수정/삭제 댓글쓰기 2008.07.15 18:26

    최근 생각하는 건.
    Action <-> Service <-> Dao 구조에서
    Action <-> Service 에서 주고 받는 객체랑
    Service <-> Dao 에서 주고 받는 객체는
    형태가 같더라도 따로 정의해 주는 것에 더 관리적 측면에서 좋다.
    머 이 이야기는 따로 정리 해야 할듯.

  4.  댓글주소 수정/삭제 댓글쓰기 2008.07.19 20:44

    첨에는 그렇게 생각하다가 나중엔 뒤죽박죽이 되어버려요..ㅜㅜ

  5. ologist  댓글주소 수정/삭제 댓글쓰기 2008.07.20 21:57

    모델의 경게에 대한 문제는 항상 설계시 고민이 되는 문제죠,.

    헷갈린 상황에서는 객체가 가능한 좁은 범위에서 의미를 갖게 하는 것이 판단의 기준이 될거 같네요.