Controller 와 Service의 차이점
레이어를 나누는 것은, 아, 티어(tier)라고도 합니다. ^^; 나누는 기준은 뭘까요. 그냥 나누는 사람도 많습니다. 레거시 코드들이 증인석에 출두할 수도 있으니까요.
2006년 스프링으로 프로젝트를 하면서 그 때는 이 고민을 하지 못했습니다. 납기일 내에 동작하는 프로그램을 만들어 내야 하니까요. 플젝이 끝나고 그것을 기반으로 확장하는 프로젝트가 많이 열렸습니다.
^^; 슬프게도 사람이 많이 바뀌었습니다. 히스토리를 알고 얘기해 줄 사람도 n모사 s모사로 가버린 다음이죠.
다행히 코드 리뷰라는 것을 새로운 플젝의 외주 사람들과 매일 규칙적으로 한시간 정도 안되게 하는데, 나온 질문입니다.
얘기가 긴 데요. It's a long story.
핵심은 request, response 같은 WAS 디펜던트 한 것을 서비스에서 처리하게 하면 안됩니다. 서비스는 WAS없이도 돌아간다라고 생각하고 짜야된다가 현재의 결론입니다.
^^;
댓글을 달아 주세요
Servier는 DB가 없이도 돌아갈 수 있어야 되기도 하죠.
Service와 Dao의 이격도 고려해봐야죠. ^^
그런 생각으로 서비스 레이어를 많이 만들기도 했는데 짜친 녀석 가지고 그러기도 뭐 해서 콘트롤러가 일 하게도 만들어봤어요. ㅋㅎ
쉽게 빠지는 코딩 방법이겠지. ^^
최근 생각하는 건.
Action <-> Service <-> Dao 구조에서
Action <-> Service 에서 주고 받는 객체랑
Service <-> Dao 에서 주고 받는 객체는
형태가 같더라도 따로 정의해 주는 것에 더 관리적 측면에서 좋다.
머 이 이야기는 따로 정리 해야 할듯.
쉽지 않아요. ^^
첨에는 그렇게 생각하다가 나중엔 뒤죽박죽이 되어버려요..ㅜㅜ
끝까지 포기하지 않고 계속 다듬어갈 필요가 있다고 생각합니다.
모델의 경게에 대한 문제는 항상 설계시 고민이 되는 문제죠,.
헷갈린 상황에서는 객체가 가능한 좁은 범위에서 의미를 갖게 하는 것이 판단의 기준이 될거 같네요.
좁은 범위에서의 의미, 좋은 개념인걸. ^^